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NOTICE 

When  Govemoent  drawings,  specifications,  or  other  data  are  used  for 
an7  purpose  other  chan  in  connection  with  a  definitely  Govemaent-related 
procurement,  the  United  States  Government  incurs  no  responsibility  or  any 
obligation  whatsoever.  The  fact  that  the  government  may  have  formulated  or 
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CO  be  regarded  by  Implication,  or  otherwise  in  any  manner  construed,  as 
licensing  Che  holder,  or  any  other  person  or  corporation;  or  as  conveying 
any  rights  or  permission  to  manufacture,  use,  or  sell  any  patented  invention 
Chat  may  in  any  way  be  related  thereto. 
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Foreword 


The  above  cartoon  has  been  around  for  some  time  and  we  often  chuckle  at  it.  But,  unfortunately,  some 
program  managers  hope  for  this  "miracle*  to  happen  when  they  realize  their  program  -  especially  in  the 
early  phases  of  the  program  -  has  not  been  developed  property.  This  Process  Guide  will  alleviate  the 
need  for  the  program  manager  to  hope  this  "miracle*  is  arourxf  if  he  ever  needs  it. 

The  Process  Guide  is  written  to  help  Aeronautical  Systems  Center  (ASC)  and  all  Air  Force  Materiel 
Command  (AFMC)  personnel  and  organizations  underhand  the  eaily  acquisition  process  and  aid  in 
developing  new,  executable  projects  prior  to  the  program  start  decision  (Milestone  [MS]  I). 

OBJECTIVE 

The  objective  of  this  guide  is  to  give  personnel  working  on  new  acquisition  projects  adequate  knowledge 
and  information  to  be  able  to  obtain  a  Milestone  I  af^oval  and  have  an  executable  program.  The 
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infonnation  is  prepared  so  personnel  at  the  Acquisition  Professional  Developnient  Program  (APOP) 

Level  I  can  understand  the  process  and  complete  the  task. 

BACKGROUND 

In  the  past,  new  acquisition  projects  often  times  were  started  in  the  XR  development  planning 
communities  that  specialize  in  studies  aixf  analyses.  The  XRs  would  interface  with  and  support  the 
operating  command  during  the  requirements  definition  process  by  defining  the  project  concept  through 
trade-off  studies  and  analyses.  Tfwy  also  provided  acquisition  strategies  and  system  program  office 
(SPO)  cadres.  However,  the  XRs  tacked  adequate  expertise  in  acquisition  strategy,  scheduling  and 
budget!^,  etc.,  to  define  the  project.  They  also  lacked  a  core  of  experience  to  apply  consistent 
acquisition  philosophy.  In  early  1992,  the  then  ASC  Commander  made  some  changes  at  the 
Aeronautical  Systems  Center  to  accomnKxfate  downsizing  Air  Force  Materiel  Command.  As  he  resized 
and  reorganized  SPOs,  he  revised  the  role  of  ASC/XR  to  concentrate  on  studies  and  analyses  and 
technical  planning  integrated  product  teams  (TPIPTs).  He  also  established  a  ‘new  starts’  SPO  to  create 
expertise  in  Phase  0,  the  Concept  Exploration  and  Definition  (CE&D)  phase,  for  new  acquisition  projects. 
This  "new  starts’  organization,  now  formally  called  the  Program  Development  SPO,  ASC/YX,  was 
fourxled  in  June  1992,  by  the  ASC  commander.  The  main  focus  for  this  new  organization  is  to  establish 
a  core  of  acquisition  exp^s  in  the  Pre-MS  I  (pre-program  start)  phase  of  a  program  by  having  this  team 
of  experts  working  solely  on  this  phase  of  new  projects. 

Acquisition  Milestones  and  Phases 
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WHAT  THE  ORGANIZATION  HAS  DONE 


ASC/YX,  subsequent  to  a  few  false  starts  and  growing  pains,  has  put  together  a  set  of  tools  that  will  help 
anyone  trying  to  initiate  a  new  project  or  a  current  program  going  through  the  Phase  0,  CE&D. 

Personnel  in  YX  researched  the  current  steps  in  the  process  to  get  a  project  from  the  Pre-MS  0  through 
the  MS  I  decision.  After  the  research,  they  laid  out  the  many  steps  in  the  process  in  an  Integrated  Flow 
Chart  (IFC).  Then  after  even  more  research,  the  SPO  men*ers  prepared  a  ’data  sheet’  for  each  task 
on  the  IFC.  You  will  see  aH  these  items,  plus  many  more,  in  this  Process  Guide.  The  YX  members  used 
the  DOD  Directive  5000.1  series  publications  as  tf^r  main  guidance  in  doing  their  research.  They  also 
researched  the  statutes,  regulations,  directives,  pamphlets,  guides  and  many  other  documents  which  are 
listed  in  each  data  sheet.  They  talked  to  respective  points  of  contact  from  many  offices  in  the  Pentagon, 
the  operating  commands,  XRs,  labs,  functional  home  offices,  schools,  staff  offices,  other  SPOs  and  the 
’greybeards’  in  YX  to  gather  the  information  contained  in  this  guide.  Use  of  the  data  in  this  guide  should 
afford  anyone  managing  or  working  on  a  project  the  proper  guidance  to  develop  an  executable  program. 


II 


ACKNOWLEDOyEMTS 


Many  people  played  an  important  part  in  preparing  this  Process  Guide.  The  list  includes  the  major 
developers,  p^ucers  and  wrtters  of  the  process. 


THE  MAJOR  CORE  TEAM; 


Lt  Col  Mike  Tankersley,  Project  Manager  Terry  Dudley 

Joe  Rosenkranz 

Lt  Col  Jim  Marks,  Project  M2mager 

Cindy  Kirchmer 

Maj  Paul  Crouse 

Charleen  Szczepanski 

Donna  Maloney 

Dave  Weber 

Maj  Lorenza  Downing 

Bob  Bryte 

Maj  Mark  Murphy 

EXPERT  CONTRIBUTORS  AND  SUPPORT 

Jim  Adams 

Jim  Austin 

Kathy  Bailey 

Trina  Bomejko 

Dean  Brigalli 

Marty  Cambra 

Julie  Cherry 

Andy  Dobo 

Capt  Mike  Farmer 

Mark  Fellows 

Lt  Col  Mort  Forker 

Sheri  Hamby 

Maj  Kim  High 

Tom  Hitzeman 

Capt  Dave  Holmes 

Rod  Hoover 

Maj  Charlotte  Hunter 

Tim  Jennewine 

Teresa  Marshall 

Gary  Martin 

Norm  Pooler 

Beverly  Powell 

Wayne  0'ConrK>r 

Lt  Col  Art  Rastetter 

Shirley  Rudduck 

Susan  Strauser 

Walter  Torrey 

Lt  Col  Harry  Walker 

Steve  Walker 

Debbie  Weber 

Mark  Weitz 

John  Wilson 

Dave  Wright 

KEY  MANAGEMENT  SUPPORT 

Col  Rob  Bongiovi 

Chuck  Corpus 

Tom  Harruff 

Dennis  Cassette 

Tom  Frysinger 

Lee  Verbillion 

OTHER  SUPPORT 


There  was  also  a  large  number  of  people  who  provided  advice,  critique,  expert  opinion,  consulting  and 
support  senrices  throughout  the  devel^ment  of  the  Process  Guide. 


QUESTIONS  OR  COMMENTS 

If  you  have  any  questions  concerning  this  process  or  Process  Guide,  please  call  ASC/YXDP,  Program 
Development  Process  Office,  (DSN  78)  51 847.  If  one  of  our  research  experts  doesnl  know  the  answer, 
we  will  find  the  answer  or  put  you  in  contact  with  the  proper  functional/operational  office. 

We  hope  this  Process  Guide  will  be  useful  to  you  in  starting  or  developing  your  project/program.  We  are 
looking  for  ways  to  make  it  better  and  more  useful.  We  would  ^jpreciate  it  if  you  send  us  any 
comments,  suggestions,  lessons  learned  or  best  practices  we  cotrid  add  to  the  guide  that  would  help 
others  in  doing  their  job.  We  have  included  a  form  at  Appendix  D  for  your  use. 
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Chapter  1 


How  to  Use  this  Guide 


THIS  PROCESS  GUIDE  BOOK 


WHO  CAN  USE? 

We  prepared  the  information  and  guidance  based  on  an  Acquisition  Category  (ACAT)  I  project/program 
and  knew  the  information  would  not  fit  everyone.  Managers  of  non-ACAT  I  projects  will  have  to  tailor 
this  information  to  fit  the  individual  project.  (Suggested  tailoring  is  discussed  below.) 

LAYOUT/ORGANIZATION 

This  guide  is  organized  in  a  top-down  manner.  Chapter  2  gives  a  macro  view,  in  big  task  fashion,  of  the 
overall  project  development  process  through  Milestone  I.  It  also  includes  a  narrative  of  that  big  task 
flow.  Chapters  3  and  4  take  those  six  big  blocks  and  give  further  breakdowns  of  the  integrated  flow  and 
an  associated  narrative  for  each.  In  Appendix  D  to  this  Process  Guide  you  will  find  detailed  task 
descriptions  -  one  for  each  task  on  the  detailed  flow  charts.  The  detail^  task  description  numbers  are 
contained  in  parentheses  at  the  end  of  each  task  narrative.  Top  and  middle  managers  will  probably  be 
interested  in  the  macro  flow  information  while  the  Project/Program  manager  aixf  his  team  of  "worker 
bees*  will  gain  valuable  information  from  the  detailed  flow  chart  and  task  descriptions. 

We  have  also  included  in  the  Appendix  other  helpful  information  such  as  definitions,  acronyms,  an  index, 
and  cross  references.  There  is  also  a  checklist  which  gives  an  irxfentured  listing  of  how  the  Pre- 
Milestone  I  process  tasks  should  take  place.  Lastly,  we  included  a  form  for  your  use  if  you  have  any 
lessons  learned  or  best  practices  you  would  like  to  contribute,  see  any  incorrect  information  or  see  any 
other  way  which  would  be  helpful  to  others  and  also  improve  this  ^ide. 

REFERENCES 

The  documents  listed  in  the  data  sheets  as  a  requirement  document  or  a  referenced  document  can  be 
found  in  a  library  located  in  ASC/YX.  Each  Data  Sheet  has  a  Lessons  Learned  category.  We  found 
some  of  those  lessons  learned  in  the  Automated  Lessons  Learned  Capture  and  Retrieval  System 
(ALLCARS)  which  is  maintained  by  ASC/CYML  (DSN  785-3454). 

TAILORING  THE  PROCESS 

As  Stated  above,  some  of  this  information  may  have  to  be  tailored  for  non-ACAT  I  projects/programs. 

The  flow  charts  in  this  guide  show  only  what  should  be  done  and  the  relationship  between  the  tasks.  It 
does  not  show  the  specific  relationship  in  time  between  tasks.  The  project/program  manager  (PM)  must 
decide  what  the  required  tasks  are  and  in  what  order  they  must  be  performed.  The  following  steps  can 
be  followed  to  aid  the  tailoring  process. 

1.  Communicate  the  PM's  goals  and  requirements  for  success.  It  is  critical  each  team  member 
understands  the  requirements  for  executing  a  project/program. 

2.  Determine  project/program  requirements.  Review  all  project/program  documentation 
prepared  to  date  for  this  knowledge  base. 
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3.  Assign  requirements  to  the  process.  This  step  determines  how  much  tailoring  the  process 
requires. 

4.  Eliminate  any  unused  portions  of  the  process  which  are  not  needed. 

5.  Add  any  missing  tasks  and  verify  the  required  processes. 

6.  Generate  prqect/program  specific  process  documents.  The  PM  and  team  use  the  tailored 
process  *o  brief  proje^program  personnel. 

7.  Prepare  a  detailed  task  flow.  Divide  the  process  into  segments  to  simplify  the  plan  for 
completing  the  project/program.  Use  a  network  scheduling  tool  to  aid  in  generating  the  duration  and 
logical  relationships  between  tasks. 

8.  Generate  a  plan  for  conducting  the  project/program.  Use  the  network  scheduling  tools  to 
build  the  network  of  ta^s  for  each  portion  of  the  project/program. 

‘These  steps  were  adapted  from  Texas  Instrunwnts  Defense  Systems  &  Electronics  Group's  Integrated 
Product  Development  Guide. 
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Chapter  2 


Figure  2*1.  Overview  of  the  Pre-Milestone  I  Acquisition  Process 


Summary 

The  life  span  of  a  new  acquisition  program  takes  it  all  the  way  from  determining  a  mission  need  to 
i  operation,  support  and  disposal  of  the  system  after  it  has  been  produced  and  deployed.  The  five  phases  g 

of  the  acquisition  process  provide  a  basis  for  conprehensive  management  and  progressive  decision 
making  associated  with  military  systems. 

The  Program  Development  Process  provides  a  detailed  flow  (via  narratives,  data  flow  diagrams  and  data 

sheets)  to  trace  a  new  project  from  the  identification  of  a  need  or  deficiency  in  Pre-Phase  0,  through  the 

development  of  alternative  approaches  in  Phase  0,  to  the  go-ahead  decision  at  MS  1 .  During  this  time  _ 

period,  the  mission  need  must  be  validated  and  the  requirements  generated.  Studies  of  alternative 

material  concepts  are  conducted  to  identify  the  most  promising  potential  solution(s)  to  the  validated  user 

needs.  The  study  results  are  evaluated,  including  the  acquisition  strategy  and  proposed  concept(s)  (with 

cost,  schedule,  risk  and  performance  objectives)  in  light  of  projected  affordability  constraints. 

The  Pre-Milestone  (MS)  0  activities  can  result  in  the  development  of  new  mission  needs.  The  activities 

in  this  phase  include  all  the  events  that  must  occur  and  documents  that  must  be  developed,  coordinated  * 

and  approved  and/or  validated  prior  to  a  MS  0  approval.  The  issuance  of  the  Acquisition  Decision 

Memorandum  (ADM)  by  the  appropriate  Milestone  Decision  Authority  (MDA)  signifies  a  MS  0  approval 

and  authorizes  the  project  to  go  ahead  for  Phase  0.  Concept  Exploration  and  DefinKion  (CE&D). 

The  Pre-Phase  0  activities  include  the  Operating  Command's  application  of  a  strategy-to-task  framework 

in  assessing  its  missions  and  identifying  deficiencies.  Those  mission  deficiencies  or  needs  that  cannot  * 

be  satisfied  by  non-material  solutions  become  the  basis  for  the  Mission  Need  Statement  (MNS).  The 

MNS  is  drafted  by  the  Operating  Command,  submitted  to  USAF/XOR  and  approved  at  the  Air  Force 

Chief  of  Staff  (CSAF)  level.  For  acquisition  category  (ACAT)  I  efforts,  the  Joint  Requirements  Oversight 

Council  (JROC)  validates  the  MNS;  for  ACAT  II  through  IV,  the  Operating  Command  will  validate  the 

MNS. 

• 

As  soon  as  the  C^eratir^  Command  has  developed  a  draft  MNS  and  has  started  the  review  cycle, 
acquisition  planning  activities  will  be  initiated  to  identify  the  desired  participants,  strategy,  organization. 
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Structure  arxl  relationships,  and  the  associated  costs  and  manpower  required  tor  Phase  0  CE&D.  The 

planning  activities  flow  back  and  forth  between  the  development  and  approval  of  the  MNS  and  tfx^e 

activities  that  are  necessary  to  plan  and  organize  for  Phase  0,  until  such  time  as  the  MNS  has  been 

approved  and  an  ADM  has  been  issued  by  the  MDA,  authorizing  the  project  to  proceed  into  Phase  0.  * 

Successful  completion  of  Phase  0  will  result  in  the  issuance  of  a  Program  Management  Directive  (PMD) 

which  authorizes  program  start  and  subsequent  program  execution.  The  everts  and  documentation  that 

take  place  in  CE&D  trace  back  to  the  origirtal  need  or  deficiency  in  the  MNS.  The  approved  and 

validated  MNS  and  the  Phase  0  plans,  are  the  basis  for  ait  activities  that  will  occur.  During  this  period, 

studies  will  be  conducted  that  explore  concept  alternatives.  The  potential  for  Non-Development  Items  i 

(NDt)  and  cooperative  opportunities  will  be  investigated,  an  alternative  systems  review  will  be  conducted, 

and  the  project  data  base  will  be  updated.  After  an  assessment  of  the  technology  needs  has  been 

accomplished,  the  operations  requirements  will  be  developed  and  documented  in  a  draft  Operational 

Requirements  Document  (ORD). 

Once  preferred  alternatives  are  defined,  a  comparative  analysis  is  developed  in  preparation  for  a  Cost  I 

and  Operational  Effectiveness  Analysis  (COEA)  and  a  Program  Alternatives  Assessment  (PAA)  will  be 
conducted.  Following  this,  the  preferred  altemative(s)  will  be  selected  and  a  cost  estimate  upfoated.  The 
program  Objective  Memorandum  /  Budget  Estimate  Submission  (POM/BES)  will  be  input  and 
subsequently  updated. 

The  preferred  attematives  wilt  include  further  definition,  along  with  appropriate  NDI  and  cooperative 

opportunities.  The  Cost  Analysis  Requirement  Document  (CARD)  will  be  developed,  the  data  base  * 

updated,  and  the  preparation  for  the  MS  1  program  cost  estimate  will  commence.  At  this  point  in  the 

acquisition  process,  the  plans  for  organizing  the  upcoming  program  are  defined.  A  system  threat 

assessment  report  (STAR),  program  baselines,  arid  testing  requirements  are  developed.  The  acquisition 

strategy  process  is  conducted  and  the  contracting  activities  are  taking  place  in  preparation  for  Phase  1 . 

The  periodic  approval  activities  consist  of  a  series  of  reviews  that  are  to  provide  the  MS  1  approval  that  * 

will  authorize  execution  of  a  formal  acquisition  program.  This  includes  validation  of  the  STAR  and 
review  and  approval  of  the  acquisition  strategy  and  contracting  activity.  High  level  reviews  and 
approvals  for  the  program  follow;  [i.e..  Air  Force  Systems  Acquisition  Review  Council  (AFSARC), 

Defense  Acquisition  Board  (DAB)  and  Joint  Requirements  Oversight  Council  (JRCX))].  Following  a 

successful  DAB  review,  a  funded  Program  Management  Directive  (PMD)  will  transfer  programmatic 

responsibilities  to  the  Implementing  Command  (i.e.  major  command,  field,  and  test  organizations)  for  I 

systems  development,  modification,  or  acquisition. 

This  document  has  been  broken  into  the  following  sections  within  Chapters  3  and  4. 

Task  0  •  Pre-Milestone  0 

I 

Task  0.1  -  Identify  Need 

Task  0.2  -  Develop  and  Approve  the  Mission  Need  Statement  (MNS) 

Task  1  -  Concept  Exploration  and  Definition  (Phase  0) 

Task  1 .1  -  Plan  and  Organize  for  Phase  0 
Task  1 .2  -  Evolve  Requirements  and  Concepts 
Task  1 .3  -  Plan  and  Organize  for  a  Program 
Task  1 .4  -  Review  and  Approve  a  Program 
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Pre-Milestone  0  Activities 


Chapter  3 


Identify  Need 


Task  0.1 


Summary 

The  Operating  Major  Commands  (MAJCOMs)  (i.e.,  ACC,  AMC,  AFSOC.  and  AETC)  and  other  Field 
Operating  fancies  (FOAs)  conduct  periodic  assessments  of  their  roles  and  overall  abilities  to  support 
the  US  Military  Strategy.  The  purpose  of  this  task  is  to  define  (and/or  refine)  their  specific  roles  and  to 
identify  mission-level  deficiencies,  shortfalls  or  oppo^nities  that  are  then  refererrced  in  the  context  of 
validated  mission  needs  (see  Task  0.2).  This  is  the  initial  step  of  the  overall  defense  acquisition  process 
and  is  typically  a  MAJCOM-driven  activity. 

Preparation  for  Task  0.1  begins  with  the  issuance  of  the  President's  National  Security  Strategy.  This  is 
based  on  input  from  the  National  Security  Council  and  {iKovides  guidance  on  national  security  interests 
and  strategies.  Key  developments  are  the  National  Military  Strategy  Document,  Defense  Planning 
Guidance  (DPG)  and  Joint  Strategic  Capabilities  Plan.  As  shown  in  Fig  3-1 ,  this  flows  directly  into 
Task  0.2  (Develop  and  Approve  Mission  Need  Statement  (MNS)). 

Direction  and  guidance  for  the  MAJCOMs  and  FOAs  are  most  often  reflected  in  the  Air  Force  Planning 
Guide.  The  S^etary  of  the  Air  Force  (SAF)  and  the  Chief  of  Staff  of  the  Air  Force  (CSAF)  provide  this 
executive  ^idance,  addressing  strat^ic  environments,  national  security  objectives,  defense  policy, 
national  military  objectives  and  planning  priorities.  It  reflects  a  summary  of  the  executive  guidance, 
fiscally  constrained  force  stnicture  levels  and  objective  assessments  of  force  capabilities. 

The  more  detailed  tasks  outlined  in  Fig  3-2  only  briefly  describe  all  the  processes  referred  to  in  the 
Task  0.1  data  flow  chart.  This  figure  nominally  indicates  the  sequence  in  which  tasks  (indicated  by  the 
chart  task  number)  should  typically  occur.  Consult  the  pertinent  data  sheet  in  Appendix  D  for  specific 
details  of  any  particular  task.  Data  sheet  task  number(s)  are  identified  in  parentheses  at  the  end  of  each 
paragraph. 
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Figure  3-3.  Task  0.1.1  -  Review  Detense  Planning  Guidance 


The  overall  (^ective  is  to  verify  that  the  roles  and  missions  being  assigned  to  the  AF  are  current  and 
consistent  with  the  latest  military  guidance.  One  activity  will  be  to  review  the  top-down  guidance  (i.e., 
National  Security  Strategy,  National  Military  Strategy,  Defense  and  AF  Planning  Guides,  Regional  Plans, 
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and  AF  Plans)  ttiat  refleds  the  national  objectives  and  strategies.  This  win  require  comparisons  with 
existing  directions  and  identifying  adjustments  as  necessary  to  stay  on  track.  Once  completed,  this 
*blessed*  guidance  is  passed  to  the  individual  Operating  Commands  in  the  form  of  their  Roles  and 
Missions. 


Tisk  0.1J2  Review  Mission  Area  Plafw 


This  is  a  biennial  activity,  led  by  the  Operating  Commands,  that  includes  an  interim  (or  annual)  update. 
The  activity  is  to  review  the  XS.  SAF  and  USAPs  most  current  guidance  on  assigned  Roles  &  Missions 
and  compare  them  with  that  contained  in  the  previous  Operating  Commands'  Mission  Area  Development 
Plan  (MADP).  The  comparison  should  include  an  assessment  of  the  MADPs  activities,  progress  and 
direction,  followed  by  any  revisions  or  updates  that  are  based  on  the  most  current  Roles  &  Missions 
guidarx:e.  The  overall  review  is  conducted  with  participation  from  the  pertinent  mission  and  functional 
Technical  Planning  Integrated  Product  Teams  (TPIPTs).  This  will  maintain  links  to  the  supporting 
elements  across  AFMC  and  will  ensure  the  lines  of  communication  are  kept  open  with  the  latest 
guidance  available.  The  resulting  status  of  the  Operating  Commands'  missions  and  supporting  activities 
are  then  made  available  to  the  Mission  Area  Assessments  task  (Task  0.1.4).  This  feedbink  would  also 
include  an  interchange  with  the  supportirrg  activities  in  industry  (Task  0.1 .3)  and  the  Laboratories 
(Task  0.1.8). 


•  • 

As  part  of  the  effort  to  review  the  Operating  Commands'  MADPs,  contacts  with  Industry  are  established 

in  order  to  review  their  progress  on  activities  supporting  developments  in  the  SPDs  and  Labs  technology 

areas.  This  is  to  ensure  that  they  are  current  and  coordinated  with  the  latest  Roles  &  Missions  updates  to 

the  MADP.  This  also  provides  an  opportunity  for  the  government  team  to  have  an  interchange  with 

industry  on  their  Independent  Research  And  Development  (IRAD)  and  Contractor  Research  and 

Development  (CRAD)  efforts.  • 


Ta^  PettoTO 


The  MAA  (Mission  Area  Assessment)  provides  the  Operating  Commands  with  feedback  on  the  tasks  that 
are  necessary  to  satisfy  their  assign^  Roles  &  Missions.  This  involves  a  breakdown  of  the  Roles  & 
Missions  into  several  regional  scenarios  that  are  outlined  in  the  DPG  and  that  are  representative  of  the 
support  expected  by  the  theater  commanders.  The  elements  (or  components)  of  these  scenarios  are 
then  defin^  in  terms  of  the  that  are  necessary  to  acconiplish  regional  objectives  (Task  0.1.7).  Key 
references  are  the  MADP  (Missbn  Area  Development  Plan)  from  the  previous  cycle,  the  latest  Roles  & 
Missbns  and  their  time  frames  (Task  0.1.2),  and  the  Operating  Commands  Concept  of  Operations 
(CONORS)  (Task  0.1.5).  Refinements  to  the  CONORS  are  also  examined.  This  assessment  provides 
the  Operating  Command  a  basis  for  defining  rxvnmand-wide  areas  of  emphasis  and  helps  focus  the 
follow-on  activities  for  the  Mission  Needs  Analyses  (MNSs)  (Task  0.1.5, 0.1.6,  0.1.7). 
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The  Concept  of  Operations  (CONORS)  of  the  Operational  Commarxl  addresses  their  operational 
structure,  capabilities,  employinent,  basing  and  interoperability  in  applying  the  fielded  weapon  systenis  in 
assigned  Roles  &  Missions.  Important  pieces  of  the  CONORS  are  the  groundrules  and  assumptions  that 
were  used  in  the  initial  determination.  It  is  also  important  to  reference  updated  key  documents  such  as 
existing  theater  war  planning  documents  and  Defense  RIanning  Guides  (Task  0.1 .1 ).  Established 
CONORS  are  periodically  reviewed  for  their  application  to  the  latest  Roles  &  Missions  assignments 
(Tasks  0.1 .4, 0.1 .7).  Efforts  should  be  made  to  include  aspects  of  joint  operations  as  well  as  individual 
Service  taskings  (Tasks  0.1 .4, 0.1.7). 


_  » 

Tt^0,1.6- Identify  Sfady  inputs 


The  purpose  is  to  develop  a  common  framework  for  the  Mission  Need  Analysis  (MNA)  (Task  0.1 .7)  and 

other  related,  supporting  analyses.  This  is  typically  achieved  by  reviewing  the  previous  cycle  needs  * 

analysis  and  updatir^  wtth  the  current  status  of  information.  Key  areas  of  focus  are  the  assumptions. 

groundrules,  scenarios,  force  structure  and  threats.  The  force  structure  should  irx^de  both  the  current 

inventory  fleet  and  account  for  any  programmed  mods/upgrades/additions  through  the  time  frame 

identified  for  the  MNA.  An  important  consideration  in  developing  the  study  inputs  is  to  ensure 

coordination  among  all  of  the  potential  players  in  the  MNA.  Documentation  becomes  one  of  the  primary 

elements  of  the  analysis  database  (Task  0.1.7).  * 
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Figure  3^.  Task  0.1.7-  Conduct  Mission  Need  Analysis  (MNA) 


The  setup  and  execution  of  the  Mission  Need  Analysis  (MNA).  a  lask-to-need*  portion  of  the  process,  is 
the  cornerstone  of  the  Operating  Conrvnand's  list  of  mission  needs.  The  focus  is  on  assessing  the 
capability  to  accomplish  identified  tasks  in  a  defirwd  set  of  conditions  (i.e.,  force  structure,  environment, 
geography,  etc.)  against  a  specified  threat.  Through  this  analysis,  the  force  shortfalls,  mission 
deficiencies,  and  capability  opportunities  are  captured  in  formal  mission  need  statements  (MNSs)  to 
represent  the  materiel  needs  of  the  Operating  Command.  During  the  process,  nonmateriel  approaches 
are  also  considered  (e  g.,  changes  to  doctrine,  tactics,  organization,  etc.)  as  a  more  efficient  and  cost- 
effective  means  of  satisfying  the  needs  (Tasks  0.1.4, 0.1.9, 0.2). 


0.1i8  -  Assess 


A  broad  overview  of  the  technology  base  is  conducted  as  the  Operating  Commands  review  their  MADPs 
in  preparation  for  the  biennial  MAAs.  This  overview  is  an  interactive  process  with  the  MADP  review.  It 
covers  the  current  and  planned  development  activities  wHNn  the  Laboratories  that  support  objectives  of 
the  supporting  commands  and  the  SPDs.  The  major  thrusts  of  the  S&T  area  (both  Labs  &  DoD)  and  the 
critical  technologies  from  DoO  are  evaluated  for  applicability  against  the  Roles  &  Missions  assigned  to 
the  Operating  Command  (Task  0.1.4). 
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Figure  34.  Task  0. 1.9  -  Identify  Potential  System  Altematives 


The  main  obj^h/e  of  this  activitiy  is  to  develop  a  stro^  analytical  basis  lor  the  evolving  material  needs 
of  the  Operating  Command.  These  efforts  are  to  provide  preliminary  system  concept  options  (PSCOs) 
to  support  the  draft  Mission  Need  Statement  (MNS)  being  put  together  by  the  Operating  Command 
(0.1 .9.1 )).  This  is  usually  an  interactive  and  formative  stage  that  identifies  the  most  iniportant  functional 
areas  to  be  covered  in  the  draft  MNS  (0.2.1 ).  Contacts  or  interfaces  are  established  with  the  AF  &  other 
Laboratories  and  with  industry  to  assist  in  development  of  the  PSCOs,  with  the  concepts  being 
developed  through  in-house  (government)  and  contracted  activities.  The  potential  for  application  of  Non- 
Developmental  Items  (NDI)  (0.1 .9.2)  and  Cooperative  Opportunities  (COD)  (0.1 .9.3)  are  investigated 
(NDI  is  synonymous  with  the  Commercial  Off-The-Shelf,  or  COTS,  acronym.).  The  Op  Cmd  also  has  the 
benefit  of  preliminary  program  cost  estimates  (0.1 .9.5)  being  defined,  which  is  a  signifcant  factor  in 
developing  their  strategy  for  prioritizing  and  allocating  resources  to  the  mission  ne^  areas.  The  most 
appropriate  PSCO  candidates  can  be  referenced  in  the  MNS  as  a  potential  set  of  altematives  that 
address  the  mission  need.  This  preliminary  development  is  also  used  in  defining  a  norrtinal  set  of  work 
statements  and  technical  plans  for  a  Phase  0  effort  (1.1).  Should  the  Op  Cmd  pursue  a  Milestone  0 
decision,  this  type  of  information  (database  -  0.1 .9.4)  is  very  useful,  especially  in  developing  an  initial 
budget  wedge  (0.1 .9.8)  for  the  POM/BES  (Program  Objective  Memorandum/  Budget  Estimate 
Submission)  that  will  identify  funding  to  support  follow-on  developments.  A  key  output  from  the  PSCO 
(and  draft  MNS)  activity  is  the  information  for  updating  the  Mission  Areas  Development  Plan  (MADP) 

(0.1 .9.6)  and  for  pulling  together  the  material  for  developing  the  annual  Technology  Investment 
Recommendation  Report  (TIRR)  that  is  transmitted  to  the  Laboratories  (0.1. 9.7). 
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Summsry 

Entrance  into  Task  0.2  begins  with  events  from  Task  0.1  (Identify  Need).  An  identified  need  is  usualy 
derived  from  intelligence  community  threat  information.  However,  it  may  also  result  from  an  operationai 
f  deficiency.  At  this  point,  the  Defense  Int^ence  Agency  (OIA)  has  provided  an  independent  threat  ^  V 

assessment  in  order  to  provide  the  material  required  for  intelligence  reports  that  may  be  required  to 
support  the  Defense  Acquisition  Board  (DAB).  Events  in  Task  1.1  (Plan  and  Organize  for  Phase  0)  flow 
in  and  out  of  this  task.  When  the  Operating  Command  determines  they  have  an  operational  need  that 
cannot  be  satisfied  by  nonmateriel  means,  they  will  prepare  a  Mission  Need  Statement  (MNS)  and 
request  an  Air  Force  decision,  through  HQ  USAF/XOR,  to  proceed  to  a  Milestone  0  decision.  Once  the 
MNS  has  been  approved,  exit  from  this  task  goes  to  Task  1 .2  (Evolve  Requirements  and  Concepts).  In  0 

this  task  various  alternatives  are  explored.  An  Operational  Requirements  Document  (ORD)  is  written, 
the  data  base  is  updated,  various  reviews  and  updates  to  cost  estimates  occur.  See  Task  1 .2  for 
complete  details  (Figure  3-1 ). 

The  purpose  of  this  task  is  to  identify  and  document  a  mission  deficiency  that  requires  a  materiel 

solution.  This  will  be  documented  in  a  MNS.  This  task  follows  the  MNS  up  to  the  point  when  a  Phase  0  • 

Program  Management  Directive  (PMD)  is  released.  The  objective  is  to  describe  the  deficierx^  in  broad 

operatioruil  capability  terms  as  well  as  to  identify  the  projected  threat  environment  and  applicable 

operational  constraints.  DoDI  5000.2  r^ires  a  MNS  to  be  completed  by  Milestone  0.  A  MNS  is 

required  for  all  potential  materiel  ac^isition  programs,  not  just  major  programs.  If  the  MNS  results  in  a 

new  major  defense  program  Acquisition  Category  (ACAT)  I,  it  must  be  sent  through  the  Air  Staff  to  the 

Joint  Requirements  Oversight  Council  (JROC)  for  review.  The  JROC's  function  is  to  review,  validate,  ^ 

and  approve  the  mission  need.  The  JROC  is  the  initial  milestone  review  link  with  the  requirements  * 

generation  system.  After  JROC  review,  it  is  sent  to  the  Defense  Acquisition  Board  (DAB)  for  review.  In 

the  instance  of  nonmajor  new  defense  programs  (ACAT  ll-IV),  the  MNS  is  validated  by  the  Operating 

Command.  It  is  then  sent  to  the  Air  Staff  for  approval  and  subsequerrtly  to  the  Air  Force  Systems 

Acquisition  Review  Council  (AFSARC)  for  a  milestone  review. 

The  more  detailed  tasks  outlined  in  Figure  3-1  only  briefly  describe  all  the  processes  referred  to  in  the  * 

Task  0.2  data  flow  chart.  This  figure  indicates  the  sequence  in  which  tasks  (indicated  by  the  chart  task 
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number)  should  typically  occur.  Consult  the  pertinent  data  sheet  in  AppencSx  D  for  specific  details  of  any 
particular  task.  Data  sheet  numbers  are  identified  in  parentheses  at  the  end  of  each  subtask  paragraph 


Figure  3<^.  Process  Flow  for  Task  0.2-  Develop  arxl  Approve  MNS 


Tasks 


I 


Task  OAl  ■  Deve6E^  D^ft  MNS 


This  task  begins  with  the  establishment  of  an  Integrated  Manpower,  Personnel  and  Comprehensive 
Training  and  Safety  (IMPACTS)  planning  team.  This  team  is  fomn^  at  the  end  of  the  Mission  Need 
Analysis  (MNA)  process  (if  a  materiel  solution  is  needed)  and  in  time  to  provide  inputs  into  writing  the 
MNS.  In^s  to  the  process,  in  addition  to  the  MNA  (Task  0.1 .7  of  Figure  3'3),  are  derived  from  an 
assessment  of  nonmateriel  alternatives  (Task  0.1 .9  of  Figure  3*3)  and  from  studies  that  may  have  been 
performed  by  advisory 
groups.  The  formal  process 
that  began  with  the 
identification,  by  the  using 
command,  of  a  need  that 
requires  a  materiel 
(hardware/software)solution 
will  continue  throughout  the 
life  of  the  system.  Outputs  to 
this  process  are  the 
Prelimirtary  IMPACTS 
Program  Plan  (P-IPP) 

(Task  0.2.1 .2  of  Figure  3-3) 
and  the  risk  assessment  to 
the  Integrated  Program 
Summary  (IPS). 


The  task  continues  with  the 
identification  of  a  mission  deficiency  or  technology  opportunity  that  requires  a  materiel  solution  based  on 
the  MNA.  This  is  determined  by  Defense  Planning  Guidance  (DPG),  assessment  of  nonmateriel 
altematives.  identification  of  a  deficiency  that  requires  a  materiel  solution,  potential  materiel  alternatives, 
threat  information,  and  constraints  to  meeting  the  need  that  include  the  results  of  the  IMPACTS  planning 
team  (Task  0.2.1 .2  of  Figure  3-3).  At  this  point,  the  preliminary  MNS  (Task  0.2.1 .1  of  Figure  3-3)  is 


MBO 


Figure  3-9.  Process  Flow  for  Task  0.2. 1  -  Develop  Draft  MNS 
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^  draftedbytheoperatingconwnandperDoD5000.2-M.  Part  2,  Attachment  I  and  API  10-601,  Attachment 

4  procedures  and  tomnat.  This  process  is  concluded  when  a  draft  MNS  is  ready  for  staff  review  and 
coordination  (Task  0.2.1 .3  of  Figure  3-3). 

The  staff  review  and  coordination  which  toHows  include  an  assessment  of  the  current  threat  information 
from  AF/IN.  It  must  be  validated  by  the  DIA  for  ACAT  I  programs  to  erasure  that  the  threat  used  to 
develop  the  MNS  will  remain  valid  up  throu^  Chief  of  Staff  of  the  Air  Force  (CSAF)  approval.  The 
overall  staffing  and  coordination  process  that  ^inates  at  the  Operating  Command  (where  the  MNS  is 
drafted),  contirxjes  through  Air  Staff  coordination,  JROC,  Senrice.  Commander  in  Chief  (CINC),  and 
Joint  Staff  coordination  (ACAT  I).  It  ends  with  validation  and  approval  by  the  JROC  (ACAT  I).  MNS  for 
ACAT  ll-IV  are  validated  by  the  operating  command,  sent  to  the  Air  Staff  for  approval,  then  presented  to 
the  AFSARC  for  milestone  review.  In  this  instance,  the  Operating  Commartd  is  the  validation  authority 
and  CSAF  is  the  approval  authority.  This  review  is  complete  when  the  MNS  has  been  approved  by  the 
operating  MAJCOM/CC  and  it  has  been  submitted  to  HQ  USAF/XOR  for  final  Air  Staff  coordination  and 
CSAF  approval  (TaskO.2.1.2.  0.2.1. 1. 0.2.1.3). 


Task  0.2.2  -  Review  and  Approve  Rna!  MNS 
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This  task  begins  when  the  MNS  is  complete  (Task  0.2.1  of  Figure  3-4).  The  threat  analyses  contained  m 
the  MNS  is  a  key  input  aruf  must  be  approved  by  AF/IN  (Task  0.2.2.1  of  Figure  3-4).  Prior  to  Milestone 
0,  the  intelligence  office  of  the  operating  command  wilt  conduct  a  strategy-to-task  analysis  to  determine 
whether  the  existing 
intelligence 
infrastructure  is 
sufficient  to  meet  the 
given  need.  This 
includes  data  flow 
and  data  bases; 
target  materials, 
mapping,  charting 
and  geodesy;  system 
interfaces;  security 
classification;  and 
personnel  and 
training.  The 
operating 
command's 
Intelligence 
Counterpart  Officer 
(ICO),  in  concert  with 
Air  Force  Intelligence 
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Figure  3-10.  Process  Flow  for  Task  0.2.2  -  Review  and  Approve  Final  MNS 


Command  and  the  Operating  and  Irnplementing  commands  requirements  staffs,  determine  the 
operational  task  associated  with  a  mission  need.  The  ICO  links  operational  tasks  to  required  intelligence 
subfunctions  and  an  intelligence  program. 


At  the  Air  Staff  level ,  HQ  USAF  ICO,  assigned  by  HQ  USAF/INX,  will  review  and  validate  the 
intelligence  infrastructure  base  for  a  given  need,  based  on  the  strategy-to  task  analysis.  HQ  USAF/IN 
(Task  0.2.2.1  of  Figure  3-4)  forwards  threat  documents  to  DIA  (Task  0.2.2.2  of  Figure  3-4)  under  a  cover 
memorandum  indicating  their  approval.  Validation  occurs  when  the  DIA  validates  the  MNS  (Task  2.2.2 
of  Rgure  3-4)  and  a  DIA  Intelligence  Report  (for  ACAT  I  only)  (Task  0.2.2.2  of  Figure  3-4)  has  been 
completed. 

The  coordination  continues  when  HQ  USAF/XOR  (which  is  the  Air  Staff  coordination  point)  receives  the 
"for  comment"  MNS  from  the  operating  command.  After  HQ  USAF/XOR  approval,  the  MNS  is  sent  to 


3-9 


Nov  93 


CSAF  for  approval.  For  ACAT I  programs,  HQ  USAF/XOR  concurrently  submits  the  final  MNS  (Task 
0.2.2.4  of  Figure  3-4)  to  the  JROC  ^cretariat  for  2-star  levef  Service,  CINC,  and  Jovit  Staff  review 
(Task  0.2.2.3  of  Figure  3-4).  It  is  complete  when  a  Service.  CINC,  arKl  Joint  Staff  coordinated  MNS  is 
ready  for  JROC  review  (for  ACAT  l)(Ta^  0.2.2.6  of  Figure  3-4)  and  a  JROC  briefing  has  been  approved; 
or,  when  notification  has  been  made  (for  ACAT  ll-IV  programs)  to  the  Milestone  Decision  Authority 
(MDA)  that  the  MNS  has  been  approved  or  disapproved.  The  JROC  briefing  must  be  given  to  the  JROC 
Secretariat  2  weeks  prior  to  the  JROC  review  and  30  days  prior  to  the  DAB.  The  result  of  the  JROC 
review  is  a  validated  MNS  and  its  associated  intelbgerKe  report  as  well  as  recommendations  and  trade¬ 
offs  on  cost,  performance  and  schedule  for  the  future  DA  review  (Task  0.2.2.7  of  Figure  3-4). 

The  next  phase  of  coordination  is  for  the  AFSARC.  The  AFSARC  (Task  0.2.2.5  of  Figure  3-4)  is 
normally  held  at  least  5  weeks  before  the  DAB  review.  Documentation  requirements  are  the  same  as  for 
a  milestone  review.  For  Milestorte  0  the  MNS  arvj  DIA  Intelligence  Report  (ACAT  I)  or  Component 
Intelligence  Report  (ACAT  ll-IV)  is  required.  The  product  from  this  review,  for  non-DAB  programs,  is  an 
Acquisition  Decision  Memorandum  (ADM).  The  sponsoring  member  wilt  prepare  the  ADM,  with 
coordination  through  the  AFSARC  Executive  Secretary,  for  sigrtature  by  the  Air  Force  Acquisition 
Executive  (AFAE)  within  5  working  days  of  the  AFSARC  review.  This  is  the  go  ahead  to  proceed  into 
Phase  0.  For  DAB  programs,  the  sponsoring  member  will  update  the  briefing  for  the  DAB  to  include 
AFSARC  findings,  coordinate  it  within  the  Air  Staff,  and  provide  the  results  to  the  Defense  Acquisition 
Executive  (DAE)  within  10  working  days  so  that  continuance  can  be  made  to  proceed  to  the  DAB. 

The  last  review  that  must  take  place  is  the  DAB  Milestone  0  (Task  0.2.2.7  of  Figure  3-4)  Review.  It  is 
held  to  determine  if  a  documented  mission  need  warrants  the  initiation  of  study  efforts  of  afternative 
concepts  and  to  identify  the  minimum  set  of  alternative  concepts  to  be  studied  to  satisfy  the  need.  Input 
to  this  review  is  a  validated  MNS,  DIA  Intelligence  Report  and  all  the  documentation  identified  by  the 
Milestone  Decision  Authority  (MDA)  or  the  responsible  committee/review  boards  that  support  the 
milestone  decision  process.  This  review  process  is  complete  when  the  ADM  has  been  approved  and 
distributed  (Tasks  0.2.2.1,  0.2.2.2,  0.2.2.3,  0.2.2.4, 0.2.2.5, 0.2.2.6,  0.2.2.7). 
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This  task  begirt  with  the  issuance  of  the  ADM  (Task  0.2.3.1  of  Figure  3-5)  the  MDA.  Upon  receipt  of 
the  ADM  from  the  MDA,  the 
appropriate  Air  Staff  office  (e  g.. 

AF/XOR)  issues  a  Program 
Management  Directive  (PMD) 

(Task  0.2.3.2  of  Figure  3-5)  which 
clearly  identifies  specific 
responsibilities  of  those  agencies 
whose  efforts  are  required  for 
completing  the  Phase  0  activities. 

The  PMD  typically  assigns  the 
implementing,  supporting, 
participating,  operating  commands 
and  test  agency.  It  also  identifies 
requirements,  as  identified  from 
the  MNS  and  related  documents, 
such  as  the  Defense  Planning 
Guidance  (DPG).  Project  specific 
information  such  as  resource 
priority  rating,  additional  constraints,  authority  and  deviations,  critical  interfaces  and  force  integration 
issues.  Army  control  treaty  verification,  project  short  title  and  resources  (financial  and  manpower)  may 
be  included  in  the  PMD.  The  PMD  is  coordinated  with  all  major  command  level  organizations  who  are 
tasked  with  direction  prior  to  it  being  coordinated  throughout  the  headquarters.  The  originating  office  is 
responsible  for  complete  distribution  of  the  final  document  in  accordance  with  SAF  Headqu, triers 
Operating  Instruction  (HOI)  800-2,  Attachment  6,  which  lists  the  mandatory  distribution  list  (Task  0.2.3.2). 


Figure  3-1 1 .  Process  Flow  tor  Task  0.2.3-  Issue  Corx:ept  Studies 
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_ Chapter  4 

Concept  Exploration  and  Definition  (Phase  0)  Activities 

_ TASK  1.1 

Plan  and  Organize  for  Phase  0 


I 


Figure  4'1 .  Overview  of  Pre-Milestone  I  AcquisHion  Process  Ftow 


•  e 


Summary 

Entrance  into  Task  1.1  begins  with  the  events  from  Task  0.2  (Develop  and  Approve  MNS).  There  is  flow 

back  and  forth  between  the  activities  in  Task  0.2  and  this  task  while  the  MNS  is  being  prepared.  The 

lead  operating  command  will  begin  planning  for  Phase  0  as  soon  as  a  draft  Mission  Need  Statement  * 

(MNS)  is  available.  Since  the  MNS  passes  through  successive  levels  of  review  and  coordination. 

approval  and  validation  and  because  only  the  most  current  MNS  should  be  used,  there  may  be 

information  that  flows  back  and  forth  between  Task  1 .1  arxJ  0.2  or  vice  versa  up  to  the  time  the  MNS  has 

been  approved.  Planning  information,  which  may  be  needed  before  the  Milestone  Decision  Authority 

(MDA)  approves  the  Ck)ncept  Exploration  and  Definition  (CE&D)  phase,  may  flow  from  Task  1 .1  to  0.2. 

A  subse^nt  return  arrow  from  Task  0.2  to  1 .1  may  indicate  guidance  provided  by  the  MDA  staff  prior  to  • 

a  Milestone  decision.  Additionally.  Task  1 .1  may  pass  updated  Phase  0  planning  information  to  Task  1 .2 
(Evolve  Requirement  and  Concepts).  It  should  be  noted  that  requirements  and  concepts  cannot  be 
formalized  until  Task  0.2  is  complete,  see  Figure  4-1 . 

The  purpose  of  this  task  is  to  determine  the  Air  Force  Concept  Exploration  and  Definition  (Phase  0) 

planning  position.  The  objective  will  identify  and  document  the  following  planning  information;  § 

•  Phase  0  purpose,  objectives,  constraints,  and  assumptions. 

•  Proposed  strategy  and  organization  for  accomplishing  Phase  0. 

•  Estimates  of  the  required  schedule  and  resources  needed  to  accomplish 

Phase  0. 

•  Content  recommendations  for  the  Phase  0  Acquisition  Decision  Memorandum  (ADM)  and  ^ 

Program  Management  Directive  (PMD).  * 
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At  this  point  the  Operating  Command  has  identified  an  operational  need  that  cannot  be  met  through 
nonmaterial  means.  Once  a  MNS  has  been  written  and  forwarded  for  Concept  Exploration  and  Definition 
(Phase  0)  review  and  approval,  the  lead  Operating  Command  should  initiate  planning  activities  to 
identify  the  desired  participants,  strategy,  organizational  structure  and  relationships,  and  associated  costs 
for  Phase  0.  The  lead  Of^rating  Command  is  responsible  for  ensuring  that  coordination,  by  each  of  the 
implementing  organizations,  has  been  accomplished  for  each  of  the  planning  effcxts  prior  to  formulating 
the  proposed  Air  Force  position  on  how  Phase  0  wilt  be  acconplished. 

The  more  detailed  tasks  outlined  in  Figure  4-2  briefly  descrft>e  all  the  processes  referred  to  in  the 
Task  1 .1  data  flow  chart.  This  figure  indicates  the  sequence  in  which  tasks  (irKficated  by  the  chart  task 
number)  should  typically  occur.  Consult  the  pertinent  data  sheet  in  Appendix  X  for  specific  details  of  any 
particular  task.  Each  data  sheet  is  identified  by  its  unique  Task  Breakdown  Structure  (TBS)  number 
which  is  identified  in  parentheses  at  the  end  of  each  subta^  paragraph. 


Figure  4-2.  Task  1.1  -  Plan  and  Organize  for  Phase  0 


Tasks 

This  task  begins  when  the  Operating  Command  determines  they  have  identified  an  operational  need  that 
they  believe  cannot  be  satisfied  by  nonmateriel  means.  The  Operating  Command  is  responsible  for 
writing  the  MNS  and  requesting  an  Air  Force  decision,  through  USAF/XOR,  to  proceed  to  a  Milestone  0 
decision.  The  lead  Operating  Command  should  initiate  planning  activities  to  identify  the  desired 
participants,  strategies,  organizational  structure  and  relationships,  and  associated  costs  and  manpower 
required  for  Phase  0  (Task  1 .1 .1 .1  of  Figure  4-3).  AFMC  Product  Centers  (PCs)  and/or  Air  Logistics 
Centers  (ALCs),  will  t^cally  provide  the  lead  Operating  Command  with  the  majority  of  the  Phase  0 
planning  information  to  support  the  potential  Air  Force  Acquisition  program  (Task  1 .1 .1 .2  of  Figure  4-3). 
The  Integrated  Weapon  System  Management  (IWSM)  philosophy  and  principles  discussed  in  AFMCP 
800-60  should  be  used  as  overall  guidance  for  establishing  a  quality  team  and  creating  a  plan  for  Phase 
0.  The  following  planning  information  is  identified  arid  will  be  documented  to  support  the  lead  Operating 
Command's  preliminary  Phase  0  planning; 

•  Phase  0  constraints  and  assumptions. 
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•  Alternative  strategies  and  organization  for  completing  Phase  0  objective. 

•  Identification  of  aH  tasks  required  to  complete  Phase  0  objectives.  These  are  documented  in  some 

form  of  work  statement  arid  coordinated  with  the  lead  O^rating  Command. 

•  Schedule  estimates  with  exit  criteria  for  completing  aU  Phase  0  objectives. 

•  Estimates  of  required  resources  needed  to  complete  Phase  0  objectives. 

•  Content  recommendations  for  the  Acquisition  Decision  Memorandum  (ADM)  and  Program 

Managemertt  Directive  (PMD). 

Creation  of  a  Project  Data 
Base  earfy  in  the  project  will 
provide  technical  information 
that  will  prove  to  be  invaluable 
when  addressing  technical 
problems/issues  in  Phase  0. 

This  key  repository  of 
information  was  developed  by 
analyses  and  simulations. 

Maintaining  interfaces  with 
laboratories  and  industry  is  also 
a  valuable  source  of 
information. 


The  following  Phase  0 
documents  are  created  (Task 
1 .1 .1 .3  of  Figure  4-3)  as  part  of 
the  technical  planning  process: 

•  Draft  Work  Statements 
that  cover  both 
government  and  industry 
tasks. 

•  Draft  Functional  Plans. 

••  Initial  Systems  Engineering  Master  Schedule  (SEMS). 

••  Strawman  Systems  Engineering  Management  Plan  (SEMP). 

•«  Initial  Integrated  Logistics  Support  Plan  (ILSP). 

••  Updated  Logistics  Support  Analysis  (LSA)  Strategy. 

••  Strawman  Program  Protection  Plan  (PPP). 

•  Draft  Strawman  Baseline  Concept  Document  (BCD). 

Another  vital  activity  in  the  planning  stage  for  Phase  0  is  the  development  of  a  contracting  strategy 
(Task  1 .1 .1 .4  of  Figure  4-3).  The  contracting  strategy  will  fulfill  the  potential  contractual  needs  of  the 
proj^  by  considering  risk,  contract  method,  period  of  performance,  etc.  The  initial  contracting  strategy 
will  include  plans  for  managing  the  contractor-conducted  Concept  Exploration  and  Definition  studies  and 
will  define  the  type  of  solicitation  and  contract  that  will  be  used  for  this  effort.  This  strategy  will  be 
incorporated  in  the  overall  initial  Phase  0  strategy  that  is  used  to  obtain  a  Milestone  I  decision. 

The  Operating  Command's  point  of  contact  may  choose  to  establish  a  Studies  Advisory  Group  (SAG) 
(optionaQ.  The  ASC  project  manager,  with  the  help  of  the  SAG  or  Operating  Command  project  officer, 
will  examine  the  activities  that  were  defined  during  Phase  0  planning  and  update  the  cost  estimates,  as 
necessary.  The  updated  cost  estimates  will  be  used  by  the  ASC  project  office  for  the  Program 
Memoraridum/Bi^et  Estimate  Submittal  (POM/BES).(Task  1 .1 .1 .5  of  Figure  4-3).  A  prerequisite  to 
POM/BES  submittal  to  the  Air  Staff  is  its  review  and  approval  by  the  Operating  Command's  ultimate 
user.  The  initial  POM  wedges  should  be  submitted  or  updated  at  the  earliest  opportunity  to  ensure  that 
all  funding  is  available  to  support  execution  of  the  planned  project  and  to  prevent  possible  schedule 
delays.  This  activity  is  completed  with  the  delivery  of  the  Air  Force  POM  to  Office  of  the  Secretary  of 
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Defense  (OSD)  on  the  first  of  April  in  even-numbered  years.  The  OSD  activity  is  oompiele  wfran  the 
Program  Objective  Memorandum  (POM)  has  been  sigiied  by  the  Secr^ry  of  Defense  in  July/August  of 
even-numbered  years.  The  key  output  of  this  task  is  a  POM  (Tasks  1.1. 1.1, 1.1 .1.2, 1.1. 1.3. 1.1.4, 
1.1.1.5.1, 1.1.1.5.2, 1.1. 1.5.3). 


lisli  Aefesign  LwKi  Centcrrs  (Air  Fof(»  Matericil  ) 

This  task  begins  foHowii^  the  receipt  of  the  PMD  from  HQ  AF/XOR.  The  PMD  provides  tasking  for  the 
program.  Tlw  AFMC  Mission  Assignment  Process  is  the  first  major  action  taken  by  HQ  AFMC  following 
the  release  of  the  PMD  by  Air  Staff.  Task  1 .1 .2  is  complete  when  AFMC/XP  assigns  the  new  mission 
task  to  one  of  the  command's  centers  of  excellence  for  execution  and  the  New  Mission  Assigrvnent 
Notification  Letter  (Letter  of  Assignment)  is  sent  to  the  Center  chosen.  A  notification  package  may 
subsequently  be  sent  to  Congress  which  explains  the  rationale  for  assigning  the  PMD  tasking  to  a 
particular  Center.  In  the  case  of  ASC,  the  task  is  entered  into  the  ASC  New  Work  Review  process  for 
internal  allocation.  AFMC/XP  makes  mission  assignments  to  the  appropriate  Center  based  on  a  set  of 
objectively  measurable  criteria  including  areas  concerning  customer  requirements,  technical 
characteristics  of  the  proposed  assignment,  present  and  future  posture  of  the  command  and  the  overall 
needs  of  the  Air  Force  and  DoD.  see  Task  1 .1 .2  of  Figure  4-2. 


Tasic  14.3  «  Assign  Lead  and  SuK)Oft  Organlza^ons  (^MC  Centers) 

This  task  begins  when  new  work  enters  an  ASC  acquisition  organization,  via  a  letter  of  assignment  from 
the  Air  Force  Materiel  Command  Mission  Assignment  Process.  This  ASC/CC  letter  assigns  to  the  lead 
and  support  Centers  any  work  that  exceeds  the  organization's  directed  mi«  '  vi,  workload  baseline, 
manpower  baseline  or  tasking  from  the  Command  Section  of  the  ASC  Co.  .cil.  The  first  step  of  the 
process  is  to  evaluate  the  new  work  for  ‘appropriateness.’  This  ensures  compatibility  of  the  work  with 
the  mission  of  both  the  ASC  and  the  acquisition  organization  to  which  the  work  will  be  assigned.  The 
corporate  level  review  portion  of  the  process  starts  by  activating  the  caretaker  (ASC/CYN)  to  assemble  a 
working  group  that  will  include  all  the  affected  organizations.  That  group  wiH  look  at  unresolved  issues 
and  recommend  a  solution  to  the  Command  Section.  At  this  point,  a  final  decision  is  reached  that  either 
resolves  the  issue  and  allows  for  the  Task  Go  Ahead"  or  returns  the  new  work  to  the  customer  with  an 
explanation  of  the  unresolvable  issue(s).  Notification  of  acceptance  of  new  work  or  formal  mission 
assignment  will  support  the  subsequent  upr^e  to  the  Phase  0  plans.  The  task  is  complete  when 
notification  of  new  work  acceptance  is  received  from  the  acquisition  organization;  a  Task  Go  Ahead  from 
the  Command  Section  or  ASC  Council  is  received:  or,  a  System  Program  Office  (SPO)  is  established, 
see  Task  1 .1 .3  of  Figure  4-2. 


Task  1.1,i4»  Update  Pha^  0  Plans 


This  task  begins  when  the  Milestone  Decision  Authority  (MDA)  is  satisfied  with  the  MNS  and  any 
requested  Phase  0  planning  information  and  approval  is  given  to  proceed  with  Phase  0  concept  studies. 
The  MDA  will  issue  an  ADM,  and  AF/XOR  will  issue  a  PMD.  Subsequent  to  receipt  of  these  documents, 
the  Operating  Command  will  update  the  Air  Force  Phase  0  (Task  1 .1 .4.1  of  Figure  4-4)  plans  to  bring 
them  in  line  with  guidance  provided  by  the  ADM  and  PMD.  When  approved,  these  plans  become  the  /Vir 
Force  baseline.  The  baseline  will  be  used  as  the  basis  for  executing  and  controlling  all  Phase  0  activities. 
When  significant  changes  are  required  to  any  of  the  plans,  rework,  recoordination  and  approval  as  wr'* 
as  rebaselining  of  the  document(s)  will  be  required.  Subsequently  the  PC/ALC  will  update  their  plans 
(Task  1. 1.4.2  of  Figure  4-4)  if  required,  and  fonward  them  to  the  lead  Operating  Command  for  review, 
approval,  and  inclusion  ii  the  Air  Force  plans.  Charters  should  be  drawn  up  and  approved,  by  the 
PC/ALC  and  user,  to  formai'y  establish  steering  or  working  groups  in  instances  where  Phase  0  plans 
identify  a  need  or  desire  for  management  or  technical  support  group  assistance. 

T^hnical  plans,  which  consists  of  the  draft  functional  plans  identified  in  Task  1 .1 .1  and  summaries  from 
prior  steering  group  for  threat,  concept,  etc.,  must  be  updated  and  preliminary  system  concept 


4-4 


No«l3 


deveiopmerKs  must  be  initiated  (Task  1 .1 .4.3.  of  Figure  4-4).  These  documents  win  form  the  basis  from 
which  technical  analysis  plans  can  be  produced  for  Government  and  contracted  activities.  Information 
derived  from  them  will  be  used  to  prepare  draft  System  Requirement  Documents  (SRDs),  draft  BCDs 
and  a  draft  Cost  and  Operational  Effectiveness  Analysis  (COEA)  Plan. 

The  data  base  (Task  1.1.4.5  of  Figure  r”l_ _ ! -  - - 

4-4)  is  continually  updated  to  provide  a  «a»  I 

central  location  for  the  collection  and  '  I 

storage  of  information/data.  This  IsnomoMictnM  iuwe«T 

informatiorVdata  will  be  used  by  the  - '  - e - 

Project  Team  to  support  decisions  they  X 

make  in  response  to  external  and  \  J  [~  u  ~  I 

internal  requirements.  Data  ba^  inputs  '  |  _ cJ  I 

result  from  updated  technical  plans,  e.g.,  i  _ t,  ,  w«ouwhwit»«i», 

updated  work  statements,  preliminary  - I  i  i*^"*^*”**  I  _  I 

COEA  plans;  preliminary  SRD;  draft  5  T  T 

BCD;  Integrated  Weapon  System 

Management  (IWSM)  Master  Plan,  _ ^  _ 

acquisition  strategy;  and,  other  approved 
pertinent  information  which  has  been 

added  after  the  data  base  was  ^ 

established.  The  inputs  are  used 

unaltered  as  outputs.  In  addition  to  data  _ c>  immte Ttnitirtii _ o  ^ 

required  to  conduct  Concept  Exploration  umatemtmmc 

Studies,  other  approved  pertinent  ‘**^‘*"T"*>  k. - J 

FK>ur.«. 


Whenever  requested,  HQ  USAF/IN,  in  concert  with  the  Defense  Intelligence  Agency  (DIA),  wMI  provide 
intelligence  and  threat  support  to  the  Concept  Action  Group  (CAG).  Note  that  CAGs  are  typically 
associated  with  ACAT  I  designated  Phase  0/1  efforts.  For  ACAT II-IV  efforts,  an  equivalent  "study  team" 
group  will  be  formed.  The  CAG,  who  is  the  lead  in  the  development  of  the  COEA  and  the  Operational 
Requirements  Document  (ORD),  is  a  study  group  formed  to  manage  Phase  0  and  must  ensure  that 
implementing  organizations  notify  HQ  USAF/IN  and  DIA  to  develop/update  threat  assessment 
documents.  These  documents  are  continuously  updated  throughout  the  acquisition  process  from 
determination  of  need  to  operational  employment.  At  the  same  time,  a  SAG  (optional)  may  be  formed. 
This  is  a  senior  level  management  oversight  group  established  and  led  by  the  lead  Opiating  Command 
to  ensure  the  Operating  Command,  the  Implementing  Command  and  decision  nnakers  continue  to  work 
together  throughout  the  development  of  Phase  0  concept  studies  and  the  COEA. 

Threat  assessments  for  all  Defense  Acquisition  Board  (DAB)  documents  wilt  be  system  specific.  When 
significant  change  in  the  threat  occurs,  especially  threat  affecting  critical  system  characteristics.  Critical 
Intelligence  Parameters  (CIPs)  and  the  CIP  Threat  Status,  the  validated  threat  assessments  will  be 
revised  and  reissued  by  the  responsible  DoD  Component  arx)/or  DIA.;  or,  an  out  of  cycle  update, 
pertaining  to  critical  program  events,  will  be  developed  and  issued.  The  update  to  Phase  0  plans  will 
result  in  intelligence  support  to  the  Air  Force.  The  irrtelligence  support  is  provided  by  the  input,  review 
and  validation  of  threat  documentation  as  it  is  initiated  by  the  acquisition  command  between  Milestone  0 
and  Milestone  I  (Tasks  1. 1.4.1, 1.1.4.2, 1.1. 4.3, 1.1. 4.4, 1.1.4.5.1, 1.1.4.5.2). 
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_ TASK  1.2 

Evolve  Requirements  and  Concepts 


§ 


Summary 

The  most  critical  task  (1 .2)  of  any  system  or  product  evolution  occurs  during  this  segment  of  the  ^ 

Phase  0  a^isition.  There  are  a  myriad  of  both  technical  and  programmatic  decisions  being  made  as 
the  (grating  command's  mission  need  is  translated  into:  a)  operational,  functional  and  system 
requirements  and  b)  a  number  of  potential  solution  alternatives  that  are  eventually  narrowed  to  one  or 
possibly  two  1)est  options’.  Normally,  the  scope  or  magnitude  of  these  potential  alternatives  will  have  a 
direct  affect  on  the  duration  of  the  task.  ACAT I  efforts  may  vary  from  9  months  to  2-3  years,  with  the  _ 

major  weapon  systems  accjuisitions  and,  in  particular,  joint  Service  activities  taking  the  longest.  Other  * 

acquisition  categories  will  t^ically  require  l^s  time  to  corr^ete,  i.e.,  3-12  months. 

It  is  very  important  for  the  project  cadre  to  have: 

a)  clear  and  reasonable  objectives, 

b)  a  firm,  defined  approach  and  direction,  * 

c)  a  complete  perspective  for  the  scope  or  magnitude  of  the  activities  that  will  develop  the  basis 
for  a  Mile^one  1  decision,  and 

d)  an  awareness  of  any  major  issues  that  will  need  resolution  or  that  could  affect  the  task's 
execution. 

Tasks  0.2  and  1 .1  must  establish  and  maintain  these  facets  of  the  overall  effort.  The  primary  goals  of  • 

Task  1 .2  are  to  provide:  a)  a  rigorous  assessment  of  requirements  and  alternative  approaches  for 

system  concepts  and  b)  a  defendable  position  for  the  soiution(s)  and  activities  that  will  be  proposed  for 

the  next  phase  (Phase  1 ).  To  be  completely  successful,  the  project  cadre  should  be  a  clo^ly  knit  IPT 

that  retains  corporate  knowledge  from  the  Pre-Milestone  0  Phase  and  the  Milestone  0  decision  event. 

Member  representation  should  come  from  across  the  Operating,  Implementing  and  Supporting 

Commands,  including  Air  Staff  and  applic^^le  Field  Operating  Agencies.  g 
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Two  inilial  activities  (see  Fig  4-2)  address  the  developmem  of  operttfionai  requirements 
(Task  1 .2.2)  and  the  exploration  of  aJtemative  system  concept  approaches  (Task  1 .2.1 ).  There  is 
significant  interaction  between  these  two.  as  trades  and  sensitivities  to  the  requirement  levels  are 
conducted  and  concept  alternatives  are  defined  and  evaluated  for  their  suitability.  In  many  cases,  these 
alternatives  are  extensions  of  the  preKminary  options  that  were  developed  in  support  of  the  MNS 
definition,  prior  to  the  MS  0  decision.  These,  and  any  additional  akemalives  identtfied  by  the  MDA.  are 
typically  referenced  in  the  ADM  and  the  PMD  for  Phase  0. 

The  time  frame  of  the  mission  need  will  influence  the  identification  of  technoto^es  that  can  be 
applied.  Normally,  the  Operating  Command's  desire  for  an  Inilial  Opmtional  CapabiKly  (IOC)  will  be 
translated  into  a  Required  Assets  Available  (RAA)  date  for  the  acquisilion  of  a  given  number  of  assets 
(equipment,  personnel  and  logistics  elements)  and  a  Techrtology  Availt^ity  Date  (TAD)  for  the 
laboratory  community's  target  for  havii^  identified  technology  cap^ities  available.  Another  area  that 
the  conc^  altemative  exploration  activity  will  also  address  is  the  application  potential  for  current  or 
projected  available  capabUilies  through  Non-Development  Herns  (NDI,  sometimes  referred  to  as 
Commercial  Off-The-Shelf  -  COTS)  and  cooperative  opportunities  with  Allied  or  other  international 
capabilities  (COD).  Although  these  are  considered  during  the  pre-MS  0  tasks  (Task  0.2).  they  are 
examined  once  again  during  the  definition  and  assessment  of  the  system  concept  aNematives. 

The  operational  requirements  activity  is  focused  on  development  of  the  ORD,  arfo  receives 
updates  from  the  trades  and  sensitivities  as  they're  corfoucted  in  the  corrcept  alternatives  activity.  The 
ORD.  and  accompanying  RCM,  is  solution  oriented  and  describes  system-specific  characteristics, 
capabilities  and  other  operational  variables.  The  draft  ORD/RCM  transitions  to  a  final  version  once  the 
results  from  a  COEA  activity  are  developed  and  validated.  The  COEA  is  conducted  to  identity/select 
preferred  aHemative(s)  through  a  comparative  analysis  of  the  various  concepts  that  have  been 
developed  and  reviewed  in  the  Program  AHematives  Assessment. 

Once  the  Operating  Command  has  identified  and  approved  the  preferred  altemative(s)  selection, 
the  POM/BES  submission  is  prepared  and  the  activity  to  further  define  the  system  concept  definition  is 
initiated.  This  concept  definition  activity  develops  the  detailed  system  descriptions  that  will  be  used  in 
the  specifications  for  potential  Phase  1  activities.  This  information  is  also  shared  with  the  task  (Task  1 .3) 
that  is  developing  plans  and  organizing  for  Phase  1  and  the  jKHivity  that  is  concluding  developtnent  of 
operational  requirements.  The  project  database  is  updated  with  the  latest  decisions  and  developments  in 
preparation  for  the  final  task  (Task  1 .4)  that  will  be  seeking  MS  1  approval. 


Figure  4-6.  Process  Flow  for  Task  1.2  -  Evolve  Requirements  and  Coneys 
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Tasks 


Thfi  task  begins  with  the  PMD  and  the  updated,  approved  acquisition  strategy  (see  Task  1 .1 ).  At  this 
time,  an  overall  acquisition  schedule  will  be  develop  and  steering  and  working  groups  wiN  be 
established  or  reconvened,  as  required.  OrKe  the  government's  objectives  and  position  have  been 
firmly  established,  the  activity  flows  into  the  procurement  of  contracted  Concept  Exploration  Studies. 
These  studies,  which  may  involve  cooperative  govemment/industry  developments,  can  be  accomplished 
if  the  work  statemerks  are  current  for  Phase  0,  the  preliminary  Cost  and  Operational  Effectiveness 
Analysis  (COEA)  plan  has  been  drafted,  and  initial  top  level  operatbnal  and  system  requirements  have 
been  defined. 

The  following  documents,  along  with  contracting  strategy  and  budgetary  requirements  to  support  the 
studies,  are  prepared: 

Preliminary  Operatkx^l  Requirements  Document  (ORO). 

Draft  System  Requirements  Document  (SRD). 

Government  Systems  Engineering  Management  Plan  (SEMP). 

Initial  Baseline  Concept  Description  (BCD)  for  each  altemative  concept  to  be  studied. 

Draft  Contractor  Systems  Engineering  Management  Plan  (SEMP). 

Systems  Engineering  Master  Schedule  (SEMS). 

Draft  Test  and  Evaluation  Master  Plan  (TEMP). 

The  output  resulting  from  this  activity  is  a  functional  architecture  for  each  altemative  conceptual  design, 
concept  design  sheets/schematic  task  diagrams  for  each  concept,  updated  BCD  for  each  concept,  draft 
9  Interface  Control  Documents  (ICDs)  for  each  concept,  a  critical  technologies  list,  an  updated  SRD, 

concept  risk  assessments  (addressing  products  and  processes,  system  performance,  schedule  and  cost), 
and  other  initial  documentation,  such  as  specification  trees.  Work  Breakdown  Structures  (WBSs),  critical 
item  specifications,  facility  requirements  and  processes  documentation. 

During  the  concept  studies,  assessments  of  needed  technology  areas  are  performed  and  any  necessary 
updates  are  examined  for  nondevelopment  items  (NDIs)  and  Cooperative  Opportunity  Developments 
(COD).  An  Altemative  Systems  Review  (ASR)  completes  the  concept  exploration  and  is  followed  by  an 
update  to  the  project  database.  (Tasks  1.2.1. 1,  .I.2.I.2. 1.2.1.3, 1.2.1.4, 1.2.1.5, 1.2.I.6. 1.2.1.7) 


TafiJc  t.23  -  Develop  Operational  Requirements 


Arrother  task  begins  with  receipt  of  the  updated  plans  for  Phase  0,  the  corK:ept  of  operations,  a  validated 
Mission  Need  Statement  (MNS),  and  results  from  the  Pre-MS  0  investigation  of  preliminary  system 
conc^  options  (SCOs).  This  permits  the  lead  operating  command  to  prepare  the  draft  Operational 
Requirements  Document  (ORD)  which  will  describe  pertinent  quantitative  and  qualitative  performance, 
operation,  and  support  parameters,  characteristics,  and  requirements  necessary  to  meet  the  MNS. 

When  the  results  from  the  COEA  (see  Task  1 .2.3)  has  received  the  Air  Force  Chief  of  Staff  (CSAF) 
appeal,  the  draft  ORD  will  begin  its  review  cycle  (that  includes  updates  from  Task  1 .2.4),  which  is 
similarly  completed  with  CSAF  approval.  An  update  of  the  Program  Objective  Memorandum/  Budget 
Estimate  Submission  (POM/BES)  will  follow. 


4r; 
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Praparation  for  the  Requirements  Summit  is  the  next  event.  Subsequent  approval  at  the  CSAF  level 
with  documentation  in  the  form  of  minutes  (of  recommendations,  action  items  and  lessons  learned) 
completes  this  task  (Tasks  1 .2.2.1 , 1 .2.2.2, 1 .2.2.3, 1 .2.2.4). 


Tiik  t  ja  “  tetentify^PreteiTisd  Attematttves 


Another  task  begins  once  a  Concept  Advisory  Group  (CAG)  has  been  established  for  the  purpose  of 
developing  arxf  proving  the  COEA  Plan.  The  CAG  will  review  the  study  team's  list  of  alternative 
solutions  which  are  reviewed  in  the  Program  Alternatives  Assessment  (PAA).  Execution  of  the  PAA  will 
ensure  that  aH  business,  financial,  and  political  risks  have  been  considered  during  Concept  Exploration 
(see  Task  1 .2.1 .).  A  comparative  analysis  will  then  be  conducted  during  the  COEA  to  assess  the 
adequacy  of  the  details  developed  for  the  alternatives  being  considered  and  to  identify  key  performance 
parameters.  This  comparative  analysis  should  reduce  the  number  of  alternatives  that  ne^  to  be 
considered  during  Phase  I  tasks.  When  this  activity  is  completed  by  the  identification  of  preferred 
altemative<s),  updates  can  be  made  to  the  cost  estimates  and  the  database.  The  selection  of  preferred 
concept  altemative(s)  that  satisfy  the  MNS  must  have  been  staffed,  coordinated  and  approved  by  the 
operating  command.  (Tasks  1. 2.3.1, 1. 2.3.2, 1. 2.3.3, 1. 2.3.4, 1. 2.3.5. 1. 2.3.6, 1. 2.3.7) 


Task  1,2.4  •  Define  PreferratlAttema^yes 


This  task  develops  the  lower  level  (Work  Breakdown  Structure  -  WBS)  details  of  the  preferred  system 
ooncept(s),  com^tes  more  of  the  documentation  needed  for  the  MS  1  approval  effort  (see  Task  1 .2.2), 
devel^  and  transfers  key  infomiation  to  the  task  that  is  preparing  for  Phase  1  progammatic  activfties 
(Task  1 .3),  and  provides  update?  .o  ti  le  project  database.  The  final  versions  of  key  documents  are 
completed,  which  apply  to  both  the  preferred  concept(s)  and  the  plans  for  Phase  1 . 

Draft  specifications  for  the  system  are  developed  through  contracted  efforts.  Also  developed  are  the 
basic  details  for  system  requirements,  risk  levels  and  potential  alternatives,  system  security,  and  work 
tasks  for  Phase  1  efforts  (Tasks  1. 2.4.1, 1. 2.4.2, 1. 2.4.3, 1. 2.4.4, 1 .2.4.5, 1 .2.4.6) . 
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Summary 

Entrance  into  Task  1 .3  begins  with  events  from  Task  1 .2  (Evolve  Requirements  and  Concepts)  and  Task 
1 .4  (Review  and  Approve  Program).  The  flow  may  be  back  and  forth  several  times  between  Task  1 .3 
f  and  Tasks  1.2  and  1.4  until  the  program  has  been  approved  for  a  program  start.  At  this  point,  the  9  # 

required  Mission  Need  Statement  (MNS)  has  been  received  from  the  Operating  Command  or  the  Joint 
Requirements  Oversight  Council  (JROC).  Other  required  documents  that  have  been  received  are  a 
Coricept  of  Operations  (CONORS)  from  the  Operating  Command  and  a  Systems  Description  from  the 
System  Program  Office  (SPO). 

The  purpose  of  this  task  is  to  initiate  and  update  the  System  Threat  Assessment  (Report)  (STA(R)),  § 

develop  the  preliminary  Acquisition  Program  Baseline  (APB)  and  Test  Evaluation  Master  Plan  (TEMP). 

Execution  of  the  Integrated  Acquisition  Strategy  Process  (lASP)  will  commence.  Other  events  that  will 

occur  during  this  task  are  the  receipt  of  drafts  of  Milestone  I  do^ments  and  functional  plans.  The 

Acquisition  Strategy  Report  (ASR)  will  be  completed  and  an  Ac^isition  Strategy  Panel  (ASP)  review 

will  be  held  to  approve  the  acquisition  strategy.  The  Acquisition  Plan  (AP)  will  be  developed  and 

contracting  activities  will  commence  such  as  training  of  the  Request  for  Proposal  (RFP)  team  who  will  P 

prepare  and  release  the  RFP.  Preparation  and  approval  of  the  Source  Selection  Plan  will  also  occur. 

This  activity  will  be  followed  by  source  selection/negotiations  and  the  award  and  issue  of  contract(s). 

The  assignment  of  lead  and  support  centers  (AFMC),  lead  arxf  support  organizations  (AFMC  Centers) 
and  the  establishment  of  a  System  Program  Office  (SPO)  wll  occur.  The  establishment  of  a  SPO 
completes  this  task. 

The  more  detailed  tasks  outlined  in  Figure  4-2  only  briefly  describe  all  the  processes  referred  to  in  the  * 

Task  1 .3  data  flow  chart.  This  figure  indicates  the  sequence  in  which  tasks  (indicated  by  the  chart  task 
number)  should  typically  occur.  Consult  the  pertinent  data  sheet  in  Appendix  D  for  specific  details  of  any 
particular  task.  Data  sheet  numbers  are  identified  in  parentheses  at  the  end  of  each  subtask  paragraph. 
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FHi^re  4-8.  Process  Flow  for  Task  1.3  -  Plar)  and  Organize  tor  a  Program 


Tasks 


T^  t.3.1r  toittateSTA(R).  APB,  andTEfc«^^^^^^^^^  ? 


The  first  task  begins  when  a  MNS  has  been  received  from  the  Operating  Command  or  JROC.  A 
CONORS  is  also  retired  from  the  Operating  Command  and  a  Systems  Description  is  required  from  the 
SPO.  Another  required  input  is  the  MAJCOM's  preferred  altemative<s)  selection.  These  documents  are 
used  to  develop  a  preliminary  STA(R).  The  STA(R)  is  the  basic  authoiitative  threat  assessment  tailored 
to  and  focused  on  a  particular  US  defense  acquisition  program.  The  Director  of  Intelligence  (Dl)  is 
responsible  for  writing  arfo  updating  the  STA(R).  It  includes  an  assessment  of  those  projected 
capabilities,  doctrine,  strategy,  tactics,  organization,  equipment  and  military  forces  that  a  potential  enemy 
could  use  to  defeat  or  degrade  the  US  system  during  its  employment.  It  focuses  on  two  specific  points 
in  time  ~  the  initial  operational  capabiKty  (IOC)  of  the  US  system  and  the  IOC  plus  ten  years  in 
accordance  with  DoDM  5000.2M,  Part  5  (Task  1. 3.1.1  of  Figure  4-9). 

The  second  task  begins  with  the  receipt  of  a  draft  Operational  Requirements  Document  (ORD), 
affordability  assessments,  a  Cost  and  Operational  Effectiveness  Analysis  (COEA),  and  conce^  definition 
studies.  These  documents  are  used  to  prepare  a  preliminary  APB.  The  APB,  whi^  is  prepared  by  the 
projed  team,  defines  the  project  in  temis  of  key  parameters  that  ideally  represent  the  most  cost  effective 
and  timely  approach  for  fielding  a  new  system  that  will  satisfy  the  mission  need.  The  APB  describes 
cost,  schedule  and  performance  objectives  for  the  program,  its  preparation  must  include  the  Operating 
CommarKfs  participation  in  each  acquisition  phase  to  ensure  th^  consistent  performance  objectives  are 
in  both  the  ORD  and  the  APB.  The  objectives  include  a  set  of  minimum  acceptable  requirements, 
(identified  in  the  ORD)  which  are  incorporated  in  the  APB,  the  TEMP  and  used  in  the  COEA  as 
thresholds  (Task  1 .3.1.2  of  Figure  4-9). 


MMt3 


The  thifd  task  begins  with 
the  extraction  of  pertinent 
threat  information  from 
the  approved/validated 
STA(R)  This  information 
will  be  included  in  the 
TEMP.  Before  the 
preliminary  TEMP  can  be 
written,  the  following 
activities  must  be 
accomplished:  the 
System  ORD  must  be 
updated  and  incorporated 
in  the  TEMP;  the  COEA 
must  be  reviewed  and 
determined  to  be 
consistent  with  the  TEMP; 
a  test  team  must  be 
formulated;  a  Test  Plan 
Working  Group/Test 
Management  Council 
(TPWG/TMC)  must  be 
established;  the  test 

requirements  must  be  validated;  the  test  concept  must  be  developed;  the  test  approach  must  be 
formulated  and  a  plan  for  resources  must  be  accomplished.  A  TEMP  is  requir^  for  all  HQ  USAF 
programs  that  are  directed  by  a  program  management  directive  (PMD).  it  provides  the  overall  stnjcture 
and  objectives  of  the  test  and  evaluation  program.  It  is  normally  prepared  by  the  TPWG.  The  System 
Program  Office  (SPO)  will  update  it,  review  it,  and  ensure  that  all  participants  (the  operating,  supporting 
#  and  operational  test  and  evaluation  (OT&E)  commands)  coordinate  on  it  prior  to  its  submittal  to  higher 
headquarters.  The  final  approval,  including  the  preliminary  plan  at  Milestone  I,  is  due  within  45  days  of 
submittal  to  the  Director  Test  and  Evaluation  (DTE)  by  the  DoD  component  (Task  1 .3.1.3  of  Figure  4-9). 

The  final  task  (Task  1 .3.1.4  of  Figure  4-9)  requires  an  update  to  the  STAR(R).  This  is  accomplished 
after  the  Requirements  Summit  has  been  conducted.  It  will  be  updated  just  prior  to  the  Milestone  I 
review  in  order  to  support  the  preferred  concept(s)  selected  by  the  MAJCOM  following  the  development 
of  the  COEA  for  Phase  0.  STA(R)s  are  required  for  all  ACAT  1C  and  1 D  programs  and  for  major 
modification  programs.  The  threat  report  for  ACAT  ll-IV  programs  is  called  a  System  Threat  Assessment 
(STA)  and  is  accomplished  by  the  Component  Command  Intelligence  Agency  or  AF/IN  for  Air  Force 
prqects.  Procedures  for  STA  are  essentially  the  same  as  for  the  STA(R). 


Figure  4-9.  Task  1.3. 1  -  Initiate  STA(R),  APB  and  TEMP 


Execute  Integrated  AcquBttion  Strati  Process  (lASP) 


Ar 
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This  task  begins  with  the  development  of  a  Roundtable  Execution  Plan  (Task  1 .3.2.1  of  Figure  4-10) 
after  the  Opiating  Command  has  made  its  selection  of  the  preferred  concept  alternatives  that  are  based 
on  the  COEA,  and  the  Implementing  Command  has  begun  its  effort  in  defining  the  preferred  concept. 

Other  inputs  to  this  plan  are  the  Preliminary  APB  arfo  the  Milestone  0  PMD.  The  development  of  the  • 

lASP  execution  plan  is  the  roadmap  for  entering  the  next  st^  in  the  lASP. 

The  subsequent  step.  Conduct  Strategic  Roundtable  (Task  1 .3.2.2  of  Figure  4-10)  is  accomplished  to 

ensure  experienced  senior  management  involvement  in  formulating  the  initial  program/project 

accfoisition  strategy.  Advice  from  the  roundtable  members  will  help  the  Program  Manger  (PM)  formulate 

the  preliminary  strategy  by;  identifying  constraints,  balancing  objectives,  setting  priorities,  providing  g 

timely  feedback,  adding  vision,  identifying  options,  and  identifying  and  managing  risk.  The  output  of  this 
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is  used  to  aid  the  PM  in  developing  the  acquisition  strategy  and  as  a  basis  for  the  upcoming  Tactical 
Roundtable. 


The  acquisition 
strategy  is 
develop 
(Task  1. 3.2.3  of 
Figure  4-10) 
based  on  inputs 
and  information 
from  the  senior 
experts  who 
were  members 
of  the  Strategic 
Roundtable  of 
the  lASP. 

These  data,  in 
addition  to  other 
gathered 
information,  are 
used  to  develop 
the  initial 
program/project 
acquisition 
strategy  that  is 
required  to  meet 
the  Operating 

Command's  needs  with  resource  constraints.  This  step  is  complete  when  the  PM  has  prepared  the  initial 
acquisition  strategy  and  included  it  in  the  first  draft  of  the  ASR  and  AP.  This  strategy  will  be  used  by  the 
Tactical  Roundtable.  The  Tactical  Roundtable  (Task  1 .3.2.4  of  Figure  4-10)  is  conducted  to  summarize 
where  the  project  is  versus  where  it  should  be:  to  describe  where  the  program  is  going  and  how  it  will  get 
there:  to  identify  project  risk  areas  and  plans  for  managing  risk:  to  provide  the  basis  for  establishing 
explicit  project  cost,  schedule  and  performance  objectives.  It  will  ultimately  provide  the  project  with  a 
systematic  approach  to  completing  a  successful  ASP  review  with  limited  manpower.  It  is  convened  soon 
after  the  PM  has  prepared  the  first  draft  of  the  Integrated  Program  Summary  (IPS)  or  ASR  and  30  days 
before  the  Tactical  Roundtable  convenes.  The  roundtable  will  be  documented  within  10  working  days 
following  completion  of  the  meeting. 

The  next  step  is  the  preparation  of  the  draft  Milestone  (MS)  I  documents  and  functional  plans 
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Figure  4-10.  Task  1.3.2  -  Execute  Integrated  Acquisition  Strategy  Process  (lASP) 
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(Task  1 .3.2.5  of  Figure  4-1 0).  The  following  documents  are  required  for  a  MS  I  decision  review; 


ACAT 

I  II  111  IV 


ORD 

X 

X 

X 

X 

STA(R) 

X 

STA 

X 

X 

X 

IPS 

X 

X 

X 

X 

Program  Life  Cycle  Estimate 

X 

X 

X 

X 

APB 

X 

X 

X 

X 

TEMP 

X 

X 

X 

X 

Component  Cost  Analysis  (CCA) 

X 

X 

X 

X 

COEA 

X 

X 

X 

X 

Defense  Intelligence  Agency  (DIA)  Report 

0 

Inteligence  Report 

0 

0 

Joint  Requirements  Oversight  Council  (JROC)  Report 

0 

Integrated  Program  Assessment  (IPA) 

0 

0 

0 

0 

Independent  C^st  Estimate  (ICE) 

0 

AcquisAion  Decision  Memorandum  (ADM) 

0 

0 

0 

0 

X:  Prepared  by  Military  Dept/PM  0:  Prepared  by  OSD  Staff 

Be  aware  that  some  of  the  functional  plans  identified  below,  that  are  required  for  MS  reviews,  are  not 
directly  reviewed  by  the  Milestone  Decision  Authority  (MDA),  but  rather  used  as  supporting  material: 

Integrated  Weapon  System  Master  Plan  (IWSMP) 

Systems  Engineering  Master  Plan  (SEMP) 

Systems  Engineering  Master  Schedule  (SEMS) 

Risk  Management  Plan  (RMP) 

Program  Protectbn  Plan  (PPP) 

Integrated  Logistics  Support  Plan  (ILSP) 

Pollution  Prevention  Action  Plan  (PPAP) 

Nuclear  Certification  Plan  (NCP)  (if  necessary) 

Cost  Analysis  Requirements  Comment  (CARD) 

Program  Management  Plan  (PMP)  (may  be  us^  on  nonmajor  programs,  but  generally  not  used 
on  major  programs) 

System  Security  Master  Plan  (SSMP) 

Computer  Resources  Life  Cycle  Management  Plan  (CRLCMP) 

The  output  to  this  step  is  the  completion  of  the  ASR  (Task  1 .3.2.6  of  Figure  4-10)  and  the  documentation 
needed  by  the  MDA  to  determine  if  the  results  of  Phase  0  warrant  establishing  a  new  acquisition  program 
and  approval  to  proceed  with  the  Demonstration  and  Validation  phase.  The  subsequent  step  in  this  task 
is  for  the  ASP  to  review  and  approve  the  aocNisition  strategy  (Task  1 .3.2.7  of  Figure  4-10).  The  ASP  is 
held  after  the  Tactical  Roundtable  and  before  the  Operational  Roundtable.  The  output  of  the  ASP  is  an 
approved  set  of  minutes  and  recommendations.  The  AP  (Task  1 .3.2.8  of  Figure  X)  is  a  top  level 
planning  document  focusing  on  the  instant  acquisition  and  its  strategies.  Contents  from  the  ASR  are 
used  to  help  prepare,  write,  and  finalize  the  AP.  Common  acquisition  strategy  paragraphs  from  the  ASR 
should  also  be  used  in  the  AP.  The  AP  is  used  to  integrate  the  acquisition  strategy  in  a  single 
comprehensive,  coordinated  plan  to  fulfill  the  Government's  needs.  It  also  serves  as  a  means  for 
documenting  the  proposed  strategy  and  obtaining  senior  level  approval  of  that  strategy.  (Tasks  1 .3.2.5, 

1. 3.2.6,  1. 3.2.7, 1. 3.2.8) 

The  Operational  Roundtable  (Task  1 .3.2.9  of  Figure  4-10)  is  a  working  group  or  a  series  of  working 
groups  designed  to  develop  and  'harmonize"  the  detailed  functional  plans  and  Milestone  directed 
documentation.  This  is  the  'write  the  plans'  portion  of  the  lASP.  Since  most  of  the  plans  will  come  to 
the  Operational  Roundtable  in  draft  form,  this  also  provides  and  opportunity  to  'facilitate'  completeness 
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the  Operational  Roundtable  in  draft  form,  this  also  provides  and  opportunity  to  'facilitate'  completeness 
and  to  'harmonize'  agreements  between  the  participants  as  to  the  content  of  each  document  and 
between  each  document.  A  list  of  the  MS  I  dements  artd  functional  plans  is  identified  in  one  of  the 
previous  paragraphs  to  the  task  identified  in  Block  1 .3.2.5.  The  output  to  the  Operational  Roundtable  is 
a  consistent  plan  for  executing  the  next  program  phase  that  has  been  recorded  in  a  set  of  documents 
and  functional  plans  that  are  consistent  with  one  another.  The  final  step  is  to  complete  the  MS  I 
documents  and  functional  plans  (Block  1 .3.2.10  of  Figure  4-10)  which  have  been  received  from  the 
Operational  Roundtable  participants. 

The  key  output  is  the  documentation/information  needed  by  the  MDA  to  determine  if  the  results  of  the 
Phase  0  warrant  establishing  a  new  acquisition  program  arid  approval  to  proceed  with  the  Demonstration 
and  Validation  (Phase  I).  (1 .3.2.10) 
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1.3.3  -  Conduct  Conttacting  Adtvities 


The  tasks  that  involve  contracting  activities  begin  with  the  establishment  and  training  of  an  RFP  team 
1 .3.3.1  of  Figure  4-11).  The  RFP  team  will  be  responsible  for  the  preparation,  timeliness  and 
of  the  solicitation.  The  following  list  of  team  members  should  be  considered  for  the  initial  team: 


(Block 
quality 

'Program  Manager 
'Systems  Engineering 
'Financial  Management 
'Reliability/Maintainability 
'Configuration/Data 
'Contracting  Officer/Buyer 
'Lead  MAJCOM  Liaison 
Clerical/Administrative  Support 
Contract  Administration  Office 
'Environmental  Management 
Key  Staff  Liaison 

'  Denotes  Typical  Core  Team  Members 


Deputy  Program  Manager 
Test  and  Evaluation 
'Legist  ics/Supportability 
'Manufacturing/Producibility 
Quality  Assurance 
Civil  Engineering 

Support  Command/Center  Liaison  (e.g.,  ATC,  ALCs) 
Joint  Service  Liaison  (e.g..  Navy,  Army,  etc.) 
Computer  Resources/Software  Engineering 
Other  USAF  activities  (e.g..  Labs.  Test  Centers,  etc.) 


The  next  step  is  to 
identify  potential  industry 
players  (Block  1 .3.3.2  of 
Rgure4-11).  This  is 
accomplished  by  early 
exploratory  discussion 
between  the  project  team 
and  industry.  This  is  the 
beginning  of  establishing 
a  source  list.  As  soon  as 
requirements  are 
kJerrtified,  the  PM  can  put 
together  a  Commerce 
Business  Daily  (CBD) 
article  that  synoposizes 
the  proposed  acquisition. 
The  output  of  the  CBD 
article  is  the  complete 
source  list  that  identifies 


Figure  4-11 .  Task  1.3.3  -  Conduct  Contracting  Activities 
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sent  an  RFP  virtien  it  is  ready  tor  release  to  industry.  The  team  will  prepare  a  draft  RFP  and  formal  RFP 
tor  the  purpose  of  transmitting  the  Government's  requirements  to  industry  (Task  1 .3.3.3  of  Figure  4-11). 

Upon  completion  of  the  RFP  team's  training  and  concurrent  with  the  RFP  preparation,  the  Source 
Selection  Plan(s)  (SSPs)  and  standards  (Task  1 .3.3.4  of  Figure  4-1 1 )  will  be  written  by  the  RFP  team. 

These  standarcte  must  be  completed  prior  to  release  of  the  RFP.  Both  the  SSP(s)  arto  the  startoards 
must  be  approved  by  the  Source  Selection  Authority  (SSA)  prior  to  release  of  the  RFP.  The  RFP  uses 
information  from  the  SSP(s)  and  standards  to  build  a  successful  RFP  (Tasks  1 .3.3.1 . 1 .3.3.2, 1 .3.3.3, 

1. 3.3.4). 

The  release  of  the  RFP  (Task  1 .3.3.5  of  Figure  4-1 1 )  canrwt  occur  until  the  applicable  reviews  and/or 
documentation,  identified  below,  have  occurred  or  b^n  received;  and  the  SSP  (if  required)  and  the  AP 
have  been  approved. 

Solicitation  Review  Board  (SRB) 

Source  Selection  Management  Group  (SSMG)  (if  competitive) 

Source  Selection  Advisory  Council  (SSAC)SSA  approval  of  the  RFP  release  (if  competitive) 

Assistant  Secretary  of  the  Air  Force  tor  Acquisition  (SAF(AQ))  (ACAT I  programs/projects) 

Under  Secretary  of  Defense  for  Acquisition  (USD(A))  (for  ACAT  I  programs/projects) 

Signed  Program  Executive  Officer  (PEO)  (if  assigned)  release  letter 

The  source  select  i  process  begins  (Task  1 .3.3.6  of  Figure  4-1 1 )  when  the  RFP  is  released  to  irvlustry. 

For  competitive  acquisitions,  the  source  selection  process  ertos  when  the  source  selection  authority 
determines  the  awardee  of  the  contract.  For  non-competitive  acquisitions,  the  process  is  complete  at  the 
corx:lusion  of  negotiations.  The  contracting  activities  are  complete  with  the  award  and  issue  of  the 
legally  binding  contract(s).  The  contract(s)  should  clearly  reflect  the  agreement  of  the  parties  and  woll  be 
consistent  with  current  law,  regulation  and  policy.  It  will  consist  of  Sections  A  through  J  of  the  RFP  that 
have  been  amertoed  as  negotiated  between  the  parties  or  as  amended  during  the  source  selection 

process.  _ 
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Task  1 .3.4  -  Assign  Lead  and  Supfwrt  Centers  (AFMG) 


This  task  begins  with  the  receipt  of  the  Milestone  I  PMD  from  HQ  AF/XOR.  Tasking  may  also  come  from 
the  ORD,  verbal  requests,  or  an  AFMC  internal  realignment  activity  and  its  resultant  documentation. 

The  AFMC  Mission  Assignment  Process  will  ensure  that  all  the  taskings  that  come  into  the  command  are 
accomplished  by  the  most  capable  and  qualified  organization.  This  will  ensure  that  our  customers  are 
provided  with  quality  service,  quality  products,  timely  response  to  customer  needs,  best  value  to  the 
customer  and  the  command  by  using  our  most  qualified  and  appropriate  resources,  and  consistency. 

The  task  is  complete  when  AFMC/XP  assigns  the  new  mission  task,  via  a  New  Mission  Assignment 
Notification  Letter,  to  one  of  the  Command  Centers  of  excellence  for  execution.  A  notification  package 
to  Congress  explaining  the  rationale  for  the  decision  may  also  be  appropriate.  The  New  Work  Review 
Process  is  the  internal  allocation  process  that  is  presently  being  used  by  the  Aeronautical  Systems 
Center  (ASC)  (Task  1 .3.4  of  Figure  4-8). 


Task  1.3.5  -  Assign  Lead  and  Support  Organizations  (Centers) 


This  task  begins  either  when  a  letter  of  assignment  is  received  from  the  Air  Force  Materiel  Command 
Mission  Assignment  Process,  an  assignment  of  a  Lead  and  Support  Center  (AFMC)  by  way  of  ASC/CC, 
or  when  any  work  that  enters  an  Acquisition  Organization  is  in  excess  of  the  organization's  Directed 
Mission,  Workload  Baseline,  or  Manpower  Baseline.  The  first  step  requires  the  acquisition  organization 
to  evaluate  the  new  work  for  ’appropriateness."  If  the  work  is  rejected,  the  rationale  for  rejection  is  - 
documented  and  it  is  returned  to  the  Command  Section  for  disposition.  This  package  is  either  returned 
to  the  customer,  explaining  the  reason  for  return,  or  submitted  to  the  Corporate  Level  Review  portion  of 
the  process.  The  process  begins  by  activating  the  Caretaker  (ASC/CYN)  to  assemble  a  working  group  of 
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the  affected  organizatior^.  Unresoived  issues  and  recommended  solutions  are  forwarded  to  the 
Command  Section.  Here  there  is  either  a  Task  Go  Ahead*  or  the  package  is  relumed  to  the  customer 
with  an  explanation  of  the  unresoivabie  issue(s).  This  task  is  complete  when  the  Acquisition 
Organization  accepts  the  new  work,  the  ASC  Command  Secton  accepts  the  Notification  of  New  Work 
from  the  Acquisition  Organization,  a  Task  Go  Ahead  is  issued  from  the  Command  Section  or  ASC 
Council  or  when  a  System  Program  Office  (SPO)  has  been  established  (Task  1 .3.5  of  Figure  4-8). 


» 


I 
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.Task:  i^.6  -  Ei^abtish  System  Program  Office  (SPO)  (LeaKi  Center^  * 

This  task  begins  with  the  formal  establishment  of  a  SPO  drat  occurs  after  a  successful  Milestone  l/IV 

decision.  At  this  point  the  SPO  cadre  expands  into  an  existing  or  new  SPO  to  accomplish  all  the  tasks 

and  activities  required  during  the  remaining  phases  of  the  acquisition.  The  direction  to  start  may  be 

derived  from  either  a  PMD  tasking,  an  Acquisition  Decision  Memorandum  (AOM)  issued  after  a  Defense 

Acquisition  Board  (DAB),  a  decision  by  the  Center  Commander,  or  a  directive  from  the  Commander  Air  * 

Force  Materiel  Commarid  (AFMC/CC).  Inputs  to  establishing  the  SPO  include  the  direction,  funding,  arxl 

the  correct  number  of  personnel  in  the  required  functional  areas  as  well  as  the  correct  number  of 

experienced  personnel  who  are  required  to  perform  the  program  tasking  (Task  1 .3.6  of  Figure  4-11).  The 

establishmerit  of  the  SPO  is  follow^  by  and  in  conjunction  with  the  contracting  activities  wherein  a 

contract  award  is  made  and  the  contract  is  issued  to  irxlustry. 
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_ TASK  1.4 

Review  and  Approve  a  Program 


Figure  4-1 2.  Overview  of  the  Pre-Milestone  I  Acquisition  Process 


Summary 

Entrance  into  Task  1 .4  begins  with  events  from  Task  1 .2  (Evolve  Requirements  and  Concepts)  where 
many  of  the  up-front  alternatives  are  explored.  A  Cost  O^ational  Effectiveness  Analysis  (COEA)  and 
Program  Objective  MemorandunVBudget  Estimate  Submission  (POM/BES)  have  been  prepared  and 
updates  to  these  documents  have  been  fed  into  this  task.  Task  1 .3  (Plan  and  Organize  for  Program) 
also  flows  into  this  task.  Many  of  the  key  documents,  e  g..  System  Threat  Analysis  (Report)  (STA(R)). 
Acquisition  Program  Baseline  (APB)  arrd  Test  and  Evaluation  Master  Plan  (TEMP)  are  developed  here. 

The  purpose  of  this  task  is  to  irtitiate  and  complete  directed  reviews  and  approvals  of  the  proposed 
program  and  to  determine  if  the  results  of  the  Phase  0  activities  warrant  a  new  acquisKion  program. 
Additionally,  the  objective  is  to  establish  the  initial  program  cost,  schedule,  and  performance  objectives. 
Up  to  this  point,  a  (Mential  program  has  evolved  requirements  with  the  Operating  Command  and  has 
developed  alternative  system  concepts  to  meet  them.  Key  documents,  Ike  the  COEA,  POM/BES  and  a 
Milestone  I  Program  Office  Estimate  (POE)  have  been  prepared.  The  System  Program  Office  (SPO) 
cadre  has  probably  already  been  formed  and  planning  is  weH  underway  tor  transitioning  the  cadre  into  a 
self-suffictent  SPO.  The  STA(R),  APB.  and  TEMP  are  being  prepared.  The  Acquisition  Strategy  Report 
(ASR),  which  has  been  prepared  by  the  development  and  user  community,  will  pass  through  several 
reviews.  The  acquisition  strategy  will  be  formulated  and  approved.  Preparation  of  the  acquisition  plan 
(AP),  Source  Selection  Plan  (SSP),  and  Request  for  Proposal  (RFP)  will  occur.  When  all  the  required 
approvals  are  received,  a  Request  for  Proposal  (RFP)  can  be  issued  and  the  award  of  one  or  more 
contracts  will  follow. 

The  more  detailed  tasks  outlined  in  Figure  4-13  only  briefly  describe  all  the  processes  referred  to  in  the 
Task  1 .4  data  flow  chart.  This  figure  indicates  the  sequence  in  which  tasks  (irxficated  by  the  chart  task 
number)  should  typically  occur.  Consult  the  pertinent  data  sheet  in  Appendix  D  for  specie  details  of  any 
particular  task.  Each  data  sheet  is  identified  by  its  Task  Breakdown  Structure  (TBS)  number  which  is 
identified  in  parentheses  at  the  end  of  each  subtask  paragraph. 
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Hgure  4-13.  Process  Flow  for  Task  1.4  -  Review  and  Approve  a  Program 


Sub-Tasks 


Task  1.4.1  -  Vatidate  SHTACR)  Pgfense  imeligeooe  Agency  <OiA> 


This  task  begins  after  the  National  Air  Intelligence  Center  (NAIC)  completes  the  STA(R).  The  DIA 
subsequently  validates  the  STA(R)  for  Acquisition  Category  (ACAT)  I  protects.  In  instances  other  than 
ACAT I  pioj^,  the  System  Threat  Assessment  (STA)  is  a)proved  by  HO  USAF/IN.  The  Air  Force 
Intelligence  Support  A^ncy  (AFISA)  nonnaiiy  briefs  the  contents  of  this  documeri  to  the  Defense 
Acquisition  Board  (DAB)  without  discussion  with  the  NAIC.  The  process  involves  the  forwarding  of  threat 
documents,  by  the  DoD  Component,  to  the  DIA.  Joint  programs  require  joint  coordination  through  the 
participating  services.  The  DIA  wM  review  and  validate  b^ed  i4)on  the  intended  use  of  the  document  to 
support  the  system  acquisition.  It  wM  stress  a>propriateness  of  the  judgments,  consistency  with  existing 
inteigence  positions,  and  logic  of  extrapolations  from  existing  inteWge^.  When  DIA  requires  changes 
or  justification  to  the  STA(R),  HO  USAF/IN  wil  forward  a  letter  to  the  DIA  certifying  that  changes  have 
been  made  or  provide  a  written  redama  with  justification  to  remain  as  is.  STA(R)s  are  developed  only 
forthe  preferred  concept  studied  in  Phased.  A  DIA  validated  STA(R)  is  required  to  support  a  program 
Milestone  I  decision.  In  addition  to  reviewing  and  validating  the  STA(R),  a  DIA  Intelligence  Report  will  be 
prepared  by  the  DIA  and  submitted  to  the  Under  Secretary  of  Defense  for  Acquisition  (USD(A),  the  Joint 
Requirements  Oversight  Counca  (JROC),  the  Component  Acquisition  Executive  (CAE),  the  Program 
Executive  Officer  (PEO)  and  the  Program  Manager  (PM).  This  task  ends  when  the  threat  contents  in  the 
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STA(R)  have  been  revievved  and  validated  by  the  DIA  (or  inclusion  in  the  Milestone  I  data  package  (Task 
1.4.6  of  Figure  4.13). 


Titrtt  t.43  -  Review  and  Approve  ASR,  AP.  lyp,  and 


This  task  begms  when  the  lead  Operating 
Command  f^ards  the  ASR,  AP,  RFP  and 
SSP  to  the  SAF/AQ  for  review.  tWaSR 
provides  the  plan  of  attack  for  the 
project/program  which  was  developed  by  the 
development  and  user  community.  The  status 
of  the  aforementioned  documents  at  this  point 
in  time  is  as  follows; 

-  The  ASR  has  been  reviewed  and 
approved  by  the  Acquisition  Strategy  Panel 
(ASP). 


-  The  RFP,  which  was  developed  by 
the  RFP  team,  should  have  completed  all 
reviews  and  be  ready  for  final  release. 

-  The  AP,  which  was  developed  with 
inputs  from  the  ASPs  approved  ASR  and  the 
RFP,  should  be  ready  for  review. 

-  The  SSP  has  been  developed  by  the 
•  RFP  team  and  is  ready  for  review. 

The  review  cycle  consists  of  the  following; 

-  The  Air  Force  Acquisition  Executive  (AFAE)  will  review  the  ASR  and  the  proposed  RFP  for 
ACAT I  programs. 

•  All  documents  are  sent  to  the  USD(A)  for  review  and  approval. 

-  After  the  USD(A)'s  review  and  approval  of  the  ASR,  the  SSP,  and  the  RFP,  all  the  documents 
are  sent  to  the  SAF/AQC. 

--  SAF/ACX)  will  send  the  approved  documents  (which  includes  the  approved  AP)  to  the 
AFAE  for  review  and  release. 


Figure  4-14.  Process  Ftow  for  Task  1.4.2  -  Review  and 
Approve  ASR,  AP,  RFP,  and  SSP 


f 
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This  sequerKing  of  events  allows  the  AFAE  the  opportunity  to  review  and  comment  on  the  ASR  and  RFP 

prior  to  being  reviewed  by  the  final  Milestone  Decision  Authority  (MDA)  (Task  1 .4.2.2  of  Figure  4-1 4)  for 

ACAT  I  programs.  An  approval  of  the  ASR  and  resultant  favorable  review  of  the  RFP  and  SSP  by  the 

USD(A)  will  cause  the  entire  package  to  be  returned  to  SAF/AQC  (Task  1 .4.2.1  of  Figure  4-14).  * 

SAF/AQC  will  send  it  to  the  AFAE  for  final  approval  of  the  AP  (thus  incorporating  any  changes).  The 

process  is  concluded  with  USD(A)  approval  of  the  ASR,  USO(A)’s  favorable  review  of  the  RFP  and  SSP 

(Task  1 .4.2.2  of  Figure  4-14),  and  SAF/AQ's  approval  of  the  AP  (Task  1 .4.2.3  of  Figure  4-14).  Approval 

of  the  AP  allows  the  program  office  to  begin  the  formal  solicitation  process  which  starts  with  the  release 

of  the  RFP. 
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This  task  consists  of  two  planing  meetings  which  are  held  at  least  180  days  prior  to  the  DAB  milestone 
review.  These  meetings  will  assess  the  program  progress  toward  satisfymg  exit  criterja  and  minimum 
required  accomplishmenls  and  the  readiness  of  the  program  to  proceed  into  the  rwxt  acquisibon  phase. 
The  flow  of  information  is  the  same  for  both  meetings  -  the  AFSARC/OAB  Planning  Meeting  and  the 
DAB  Planning  Meeting.  Information  required  for  these  meetings  consists  of  the  fobbing;  Cost  Analysis 
Requirements  Document  (CARD);  a  proposed  Int^ated  Program  Summary  (IPS)  outline;  the  status  of 
progress  toward  satisfying  exit  crileha  as  defined  in  the  Acquisition  Decision  Memorandum  (ADM)  from 
the  previous  Milestone  Decision;  the  status  of  progress  toward  satisfying  the  minimum  required 
accomplishmenls  as  defined  in  DoDI  5000.2,  Part  3;  any  potential  issues,  a  schedule  of  effort  to  be 
accomplished  to  allow  the  program  to  proceed  to  the  DAB;  and  the  current  program  status.  The  resultant 
documentation  is  a  Maior  Issues  Guidance  (MIG)  memorandum  (Committee  Memo),  a  master  planning 
calendar  and  an  Independent  Cost  Estimate  (ICE). 


_ _ T—k  1.4.4  -  Conduct  Component  Ck)st  Analysis  (CCA)  _ 

This  task  begins  when  the  completed  CARD  is  used  as  input  data  to  the  CCA.  This  information  which 
includes  the  project  as  currently  planned  and  all  cost  categories,  i.e.,  investment,  appropriation,  test  arxj 
evaluation,  procurement,  military  construction,  operation  and  maintenance,  and  military  personnel  is 
used  by  the  CCA  team  to  develop  the  CCA  report.  The  draft  CCA  will  be  provided  to  the  Cost  Analysis 
Improvement  Group  (CAIG)  no  l^er  than  51  calerxlar  days  in  advarx^e  of  a  scheduled  DoO  comportent 
milestone  or  project  review.  The  results  will  eventually  be  used  when  the  AFSARC  review  is  convened 
to  review  ACAT I  acquisition  programs  prior  to  a  Milestone  Decision  being  made  by  the  DAB  or  prior  to  a 
program  review  by  the  Secretary  of  Defense.  Note:  The  AFSARC  functions  as  the  DAB  for  all  Air  Force 
programs  that  are  less  than  ACAT  I.  All  three  reviews  are  similar,  although  at  different  levels  of  review. 
Each  review  looks  at  all  the  program  documentation  necessary  for  a  program  decision  to  go  ahead  or  for 
the  continuance  of  an  existing  program. 


Task  1.4.5  •  Conduct  Air  Force  CAIG  Review 


This  task  begins  when  the  AFSARC  scheduling  group  schedules  an  AFSARC  review.  This  activity  starts 
the  preliminary  activities  on  the  CAIG.  Cost  information  in  the  form  of  the  CCA  (formerly  known  as  the 
ICE),  CARD,  POE  and  COEA  are  necessary  for  the  CAIG  review.  Preparation  for  the  CAIG  review  is 
accomplished  through  both  planning  meetings  and  status  reviews  which  are  convened  to  ensure  that  all 
information  needed  during  the  formal  CAIG  review  is  accomplished  on  schedule  and  with  the  required 
quality.  The  result  of  the  review  is  the  CAIG's  devekjpmenf  of  the  Air  Force  cost  position  (SCP).  This 
reflects  the  position  of  the  Secretary  of  the  Air  Force.  TWs,  in  turn,  provides  approval  to  submit  the 
COEA,  CCA  and  POE  to  the  AFSARC. 


Task  1.4.6  -  Review  Mitestone  Documentation  (AirForce) 

This  task  begins  with  receipt  of  draft  documentation  to  include  the  Operational  Requirements  Document 
(ORD);  toe  STA(R),  the  Intelligence  Refwrt;  the  IPS,  the  Program  Life  Cycle  Cost  Estimate  (PLCCE),  the 
APB*;  the  TEMP*;  the  ICE*;  the  COEA,  the  Pollution  Prevention  Action  Plan  (PPAP);  and  the  Program 
Protection  Plan  (PPP)  by  the  AFSARC  Executive  Secretary.  This  documentation  must  be  received  at 
least  24  days  prior  to  the  planned  AFSARC  meeting.  The  meeting,  which  is  chaired  by  toe  AFSARC 
Committee  Chair  (or  a  representative),  will  include  representatives  of  the  Committee  principals  and  will 
be  held  approximately  10  calendar  days  before  an  AFSARC  review.  Review  of  the  identified 
documentation  sen/es  as  a  vehicle  for  identifying  and  reviewing  major  questions  raised  by  the  draft 
documentation  pertaining  to  program  technical  content  and  risks,  cost-effectiveness,  threat,  acquisition 
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Strategy,  supportability  artd  produdbilily.  test  plans  and  results,  and  status  since  the  planning  meeting. 
The  product  of  the  documentation  review  is  a  Commitlee  Memo  (prepved  within  5  days  of  completion  of 
the  review)  to  the  AFAE  from  the  Committee  Chair. 

*Required  by  Congress. 


Task  t.4.7  <  Conduct  AFSARC  Review 


a 


a 
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This  task  begins  with  all  necessary  documentation 
being  prepared.  For  ACAT I  programs,  the 
AFSARC  is  normally  held  5  weeks  prior  to  the  DAB 
review.  Other  AFSARC  meetings  will  be  held  as 
determined  by  the  AFAE.  The  sponsoring  member 
is  responsible  for  ensuring  that  the  AFSARC  is 
scheduled  for  those  programs  (idersified  as  non- 
DAB  programs)  whk^  require  only  the  AFSARC 
review.  The  documentation  requirements  are  the 
same  as  for  a  milestone  review.  See  Figure  4-1 5 
for  list  of  documentation. 

Rgure4-15:  Documentation  Needed  for  AFSARC 
The  AFSARC  process  implements  OoOl  5000.2,  Review 

Section  1 1-C,  for  AFAE  review  of  ACAT  I 

programs,  any  joint  program  for  which  the  Air  Force  is  the  lead,  and  ACAT  ll-IV  programs  as  determined 
by  the  Secretary  of  the  Air  Force  (SAF)  or  the  AFAE.  The  AFSARC  is  convened  to  review  programs  prior 
to  any  milestone  decision  by  the  DAB  or  prior  to  a  program  review  by  the  Secretary  of  Defense.  It  is  the 
Air  Force  review  process  which  reviews  all  program  documentation  prior  to  going  to  the  DAB.  The 
AFSARC  functions  as  the  DAB  for  all  Air  Force  programs  that  are  less  than  ACAT  I.  The  AFSARC  is 
held  in  addition  to  both  the  Summit  and  the  DAB  process.  All  three  of  these  reviews  do  essentially  the 
same  thing  at  different  levels  of  review.  Each  review  looks  at  all  the  program  documentation  in  order  to 
make  a  decision  for  either  a  program  go  ahead  or  continuance  of  an  existing  program.  The  result  of  this 
review  for  non-DAB  prr^rams  is  the  AFSARC  sponsoring  member  will  prepare  an  ADM  for  the  AFAE 
signature  within  5  w^ing  days.  For  DAB  programs  the  sponsoring  AFSARC  member  will  update  the 
IPS  to  include  AFSARC  findings,  coordinate  within  the  Air  Staff,  and  provide  it  to  the  Defense  Acquisition 
Executive  (DAE)  within  10  working  days. 

’Required  by  Congress. 


. %  > 

ORD 

ORD 

STAR 

STA 

DIA  INTEL  REPORT 

COMPCM^ENT  INTEL 
REPORT 

JROC  ASSESSMENT 

N/A 

IPS 

IPS 

IPA 

IPA* 

PLCCE 

PLCCE 

APB 

APB* 

Task  1.44  -  Conduct  OSD  CAIG  Rev^ 


This  task  begins  when  the  Air  Force  Cost  Analysis  Improvement  Group  (AFCAIG)  reviews  all  the  CCAs, 
the  CARD,  the  POE,  and  the  SCP.  The  AFCAIG  advises  the  Assistant  Secretary  of  the  Air  Force  for 
Rnancial  Management  (SAF/FM)  on  their  technical  adequacy,  validity,  and  reasonableness.  CCAs  must 
be  reviewed  by  the  CAIG  prior  to  the  AFCAIG  review.  Additionally,  the  POE  and  CCA  nust  be  approved 
by  the  Component  Secretary  before  submission  to  Office  of  Secretary  of  Defense  (OSD).  The  review  of 
these  documents  wilt  determine  whether  cost  estimating  deficiencies  exist  in  these  estimates  or  the 
associated  documentation.  The  AFCAIG  also  validates  the  methodologies  used  to  make  the  estimates 
and  determines  if  additional  cost  studies  are  required.  These  estimates  are  used  by  the  OSD  CAIG  to 
develop  its  estimate  of  the  program  life  cycle  costs.  The  CAIG  review  occurs  after  the  Documentation 
Review  but  not  later  than  21  days  before  the  DAB.  The  resultant  OSD  CAIG  estimate,  along  with  the 
OSD  CAIG's  test  for  reasonableness  of  the  POE,  CCA,  and  SCP,  is  included  in  the  DAB  Committee's 
Integrated  Program  Assessment  (IPA). 


•  • 
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This  task  begins  with  receipt  of  the  draft  documentation  shown  in  Figure  4-16,  by  the  DAB  Executive 
Secretary,  at  least  45  days  prior  to  the  planned  DAB  Committee  meetir^. 

This  review  serves  as  the  single  OSD  meeting  for  identifying  arxf  reviewing  major  questions  raised  by 
the  draft  documentation  and  any  new  program  developments  since  the  planning  meeting  in  preparation 
for  the  DAB  for  ACAT I  programs.  It  includes  a  preservation  of  the  program  technical  content  and  risks, 
cost  effectiveness,  threat,  acquisition  strategy,  supportabiiity  and  pitxkjcibility,  test  plans  and  results  and 
a  status  update  since  the  planning  meeting.  The  results  of  the  Documentation  Review  are  documented 
in  the  Guidance  Update  Memorandum  (GUM).  This  e  prepared  within  5 
days  after  the  review  and  submitted  to  the  DoD  Component  Acquisition 
Executive  by  the  Committee  Chair.  Any  adjustments  to  the  final 
documents,  which  may  have  been  identified  in  the  documentation  review, 
must  be  submitted  in  final  form,  under  the  signature  of  the  AFAE,  to  the 
DAB  Executive  Secretary  no  later  than  10  days  prior  to  the  DAB  Committee 
Review.  See  Task  1 .4.9.2  of  Figure  4-6. 

The  OSD  Committee  Review  will  follow;  however,  it  cannot  begin  until  the 
project  manats  report  on  the  elements  to  be  addressed  for  a  milestone 
review  is  available. 

This  includes  a 
Committee 
Memorandum 
documenting  the 
results  of  the 
Documentation 
Review  signed  by 
the  Committee 
Chair;  final 
documentation  with 
a  Cover 
MemorarxJum 

Signed  by  the  DoD  Component  Acquisition  Executive  (includes  the  IPS  and  associated  annexes  as  well 
as  other  required  stand-alone  documentation)  and  DoD  assessments.  This  review  is  concluded  when  an 
independent  assessment  has  been  completed  and  documented  in  an  IPA  and  Committee  Memorandum 
for  DAB  review  (Task  1 .4.9.3  of  Figure  4-1 7). 


Figure  4-17.  Process  Flow  for  Task  1.4.9  -  Conduct  Milestone  I  Reviews 
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The  committee  staff  specialist  will  provide  committee  members  documentation  at  least  1 0  days  prior  to 
the  review.  TheCommMee 
Executive  Secretary  will 
provide  a  read  ahe^  (Blue 
Book)  (covering  the 
documentation  listed  in 
Figure  4-18  which  is  identified 
in  DoDI  5000.2,  Part  13, 

Section  B)  to  all  committee 
members  at  least  2  working 
days  in  advance  of  the 
Committee  review  identifying 
the  issues  to  be  discussed  at 
the  review.  This  Blue  Book 
includes  inputs  from  the  DoO 
Component  and  OSO  offices 
and  addresses  topics  which 
need  to  be  reviewed  prior  to  a 
Milestone  I  decision. 


This  process  ends  when 
sufficient  information  is 
available  to  complete  an 
indeperKfent  assessment 
which  will  be  documerrted  in 
an  IPA.  The  IPA  documents  OSD's  independent  assessment  of  the  potential  program.  It  toHows  the 
format  of  the  IPS.  The  IPA  and  a  memorandum  which  will  be  submitted  to  the  DAB  Chair,  should  be 
prepared  by  the  Committee  staff  specialist  within  5  days  after  the  Committee  review  for  Milestone  I  (See 
Ta^  1 .4.9.4  of  Figure  4-17). 

The  IPA  is  fonwarded  with  a  memorandum  to  the  DAB  members.  The  next  step  begins  when  the  when 
the  OSD  Committee  Review  is  complete  and  recommendations  are  available  to  document  the  IPA 
(Tasks  1. 4.9.1, 1. 4.9.2, 1. 4.9.3, 1. 4.9.4). 


IPS 

APB 

DoO(C)  Rnarvaal  Status  Assessment 

DIA  Intelligence  Report 

PA&E  Affordability  Assessment 

PA&E  Cost  &  Operational  Effectiveness  Analysis  (COEA)  Assessment 

PA&E  CAIG  Assessment 

Joint  Requirements  Oversight  Council  (JROC)  Assessmera  (if 
available) 

Development  Test  &  Evaluation  (DT&E)  Assessment 

Operational  Test  &  Evaluation  (OT&E)  Assessment 

DUSD(IP)  Cooperative  C^jportunity  Assessment 

FM&P  HSI  Assessment 

P&L  Producibility  and  IrKkJstrial  Base  Assessment 

P&L  Supportability  Assessment 

P&L  Environmental  Assessment 

Figure  4*1 8.  Documentation  Needed  for  OSD  Committee  Review 


(Milestone  I) 


S) 


Ar 
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Ta^  1.4.10  -  Conduct  Joint  Requirements  Oversight  Counct!  (JROC)  Requirements 
_  Rewew  and  VaBdattion 


This  task  begins  after  completion  of  the  AFSARC  review  and  upon  receipt  of  the  draft  APB.  This  occurs  • 

no  less  than  59  calendar  days  prior  to  a  scheduled  DAB  review.  The  input  from  the  AFSARC  is  either  an 

ADM  for  non-DAB  programs  or  an  updated  IPS  for  DAB  programs.  All  the  documents  identified  for  a 

AFSARC  review  are  also  required.  See  Task  1 .4.7  and  Figure  4-1 5  for  a  complete  list.  The  review 

ensures  that  performance  objectives  and  thresholds  that  are  in  the  draft  APB  provide  a  capability  that  will 

satisfy  the  mission  need.  Since  these  objectives  are  derived  from  the  ORD  and  the  results  of  the  COEA, 

the  program  sponsor  ensures  the  briefing  reviews  the  Mission  Need  Statement  (MNS),  identifies  the  • 

related  threat  and  describes  how  the  proposed  performance  objectives  and  thresholds  will  satisfy  the 

mission  need.  The  JROC  provides  its  recommendations,  via  a  written  assessment,  to  the  DAB 

(Task  1.4.10). 


T^8k  i  .4111  -  Conduct  PAB  M^^  Review 


This  task  is  the  last  major  review  which  will  occur  to  a  project  as  part  of  the  review  and  approval  cycle  of 
a  project.  Its  purpose  is  to  allow  the  Milestone  Decision  Authority  (MDA)  to  decide  whether  or  not  a 
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proj^  should  proceed  into  Phase  I,  Demonstration  and  Validation.  The  locus  is  on  the  OSD  Committee 
Chair's  summary  of  the  issues  and  recommendations  from  the  OSD  Committee  Review.  The  data 
necessary  for  the  DAB  review  consists  of  the  Read  Ahead  (also  termed  Blue  Book)  which  includes 
pertinert  project  documentation  and  briefings  and  the  IPA  .  The  IPA  documents  the  issues  and 
recommendations  of  the  OSD  Committee  Review.  The  DAB  wiN  locus  on  issues,  affordability, 
altemalive,  trades,  and  exit  criteria.  The  Program  Manager  can  recommend  alternatives  to  bie  pursued. 
The  DAB  recommends  to  the  USD(A)  whether  or  not  a  program  should  be  granted 
demonstratiorVvalidatioiVmajor  modification  approval.  The  result  of  this  review  is  an  approved  ADM 
which  approves  the  initiation  of  a  new  program  for  entry  into  Phase  I,  approves  the  proposed  or  modified 
acquisition  strategy  (and  Concept  Baseline  for  Phase  I),  establishes  program  specific  exit  criteria  that 
must  be  accoinplished  during  the  Phase  I/modification  and  identifies  affordability  constraints  derived 
from  the  planning,  programming  and  budgeting  system  (Task  1 .4.1 1 ). 


Task  1.4.12  -  issue  Program  Oirediort 


This  task  begins  when  the  — 

ADM  has  been  issued  by  i - ' 

theMDA..  Upon  receipt  I 

of  the  ADM  from  the  MDA  I  . 

(Task1.4.12.1  of  Figure4-  u  _  ^  — 

19),  the  appropriate  Air  oAsmoo^oM.*  \  ~i 

Staff  Office  Program  ^ - 1 - ,  _st _  _ 

Element  Monitor  (PEM)  '  I  AcoumoN 

or  designated  office  of  IcoMoucTAnAiie  ^  Mm  and  mm  n 

responsibility  will  write  i_  _^****'  _l  — i —  _ / -  [-° — 

and  issue  a  Program  f'  f  ^  „.?g!SiiL 

Management  Directive  ^  J  amemt 

(PMD)  Task  1 .4.12.2  of  ^  f  ^ 

Figure  4-19).  A  PMD  will  | - .v - 1 _ 9 _ i _ 9 _ , 

not  be  issued  unless  the  '  ,.j  , 

program  has  planned  I  AtA»iAAOo«oAi«eAOAPiiooAAii  . 

funding  or  has  prior  year  l _ _ ' 

funding  which  is  identified  _ ' 

in  the  President's  Budget  Figure  4-19.  Process  Flow  for  Task  1.4. 12  -  Issue  Program  Direction 
and  the  Future  Years  Defense  Program  (FYDP).  Also,  the  program  must  have  at  least  one  validated 
requirements  document,  e.g.,  MNS  or  ORD.  The  PMD  is  coordinated  with  all  major  command  level 
organizations  tasked  with  direction  prior  to  being  coordinated  throughout  the  hea^arters.  The  PMD 
will  direct  programmatic  responsibilities  to  major  command,  field,  and  test  organizations  for  systems 
development,  modification,  or  acquisition  in  broad  terms.  All  Air  Force  acquisition  programs  are  required 
to  have  a  complete  and  current  PMD  (Task  1 .4.1 1 , 1 .4.12.2). 
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APPENDIX  A 
GLOSSARY  OF  TERMS 


NOTE:  The  purpose  of  this  glossary  is  to  help  the  reader  urKterstaixf  some  of  the  terms  used  'n  ihis 
process  guide.  It  is  not  intended  to  encompass  all  terms  relating  to  the  acquisition  process.  For 
standardized  definitions  and  terms  for  Department  of  Defense  and  Air  Force  use,  refer  to  Joint 
Publication  1-02,  Department  of  Defense  Dictionary  of  Military  and  Associated  Terms,  1  May  1988,  and 
AFM  1 1  -1 .  A/f  Force  Glossary  of  Standardized  Terms. 


Acquisition  -  The  process  for  obtainir^ 
sy^^tems,  equipment  or  rrudifications  to  existing 
inventory  items. 

Acquisition  Categories  (ACATs)  -  DOD 

acquisition  programs,  both  -najor  and  nonmajor, 
are  classified  into  one  of  four  acquisition 
categories  (ACATs).  These  categories 
determine  the  level  of  review,  decision 
authority,  and  applicable  procedures.  These 
categories  are  similar  to  those  used  by  the  Navy 
for  a  number  of  years. 

ACAT  ID  -  The  primary  criteria  is  $300M 
Research  Development  Test  and  Evaluation 
(RDT&E),  $1 .88  Procurement  (FY90  constant 
$).  Milestone  Decision  Authority  (MDA)  for 
these  programs  is  the  Under  S^retary  of 
Defense  for  >yx)uisition  (USD(A)).  The 
Milestone  review  forum  is  the  Defense 
Acquisition  Board  (DAB). 

ACAT  1C  -  The  primary  criteria  is  $300M  RDTE, 
$1 .88  Procurement  (FY90  constant  $). 

Milestone  Decision  Authority  (MDA)  is  delegated 
by  the  USD(A)  to  the  DoD  Component  Head. 
Decision  authority  may  be  delegated  no  further 
than  the  Service  Acquisition  Executive  (SAE). 
The  Milestone  review  forum  is  the  Air  Force 
Systems  Acquisition  Review  Council  (AFSARC). 

ACAT  II  -  The  primary  criteria  is  approximately 
$11 5M  RDT&E,  $540M  Procurement  (FY90 
constant  $).  Milestone  decision  authority  is 
delegated  no  lower  than  the  DoD  Component 
Acquisition  Executive. 

ACAT  III  -  High  visibility,  special  interest 
programs.  This  category  would  not  have  dollar 
thresholds.  Programs  are  assigned  to  this 
category  based  on  their  overall  importance. 


degree  of  risk  involved,  ar>d  need  for  higher 
management  vistoibty  and  decisionmaking  as 
determined  by  each  DoD  Component  SAE.  The 
level  of  decision  authority  for  this  category  may 
inckide  Program  Executive  Officers  (PECte)  artd 
the  commanders  of  the  Military  Department 
logistics,  systems,  and  materiel  commands  as 
determined  by  the  Corr^nent  SAE. 

ACAT  IV  -  This  category  would  include  those 
acquisition  programs  not  otherwise  designated 
as  ACATs  I,  II  or  III.  The  level  of  decision 
authority  for  programs  in  this  category  shall  be 
at  the  bwest  level  deemed  practicable  by  the 
Component  SAE. 

Acquisition  Decision  Memorandum  (ADM)  - 
A  nrerTxvandum  signed  by  the  Milestone 
Decision  Authority  (MDA)  that  documents  the 
decision  made  arid  the  exit  criteria  established 
as  the  result  of  a  milestone  decision  review  or 
in-process  review. 

Acquisition  Executive  System  -  The  AFAES  is 
a  management  system  with  the  underlying 
principle  that  program  management  authority 
and  responsbility  must  be  placed  at  the  lowest 
level.  At  the  same  time,  the  AFAES  establishes 
accountability  arxf  provides  visibility  for  the  Air 
Force  Acquisition  Executive  to  oversee  and 
guide  Air  Force  programs.  Key  to  the 
effectiveness  of  this  system  is  a  timely  and 
unrestricted  information  flow  among  the  Air 
Force  Acquisition  Executive  -  Program 
Executive  Officer  -  Program  Director  (AFAE  - 
PEO  -  PD)  aiKf  appropriate  accountability  at  all 
levels  of  the  system. 

Acquisition  Life  Cycle  -  Five  phases,  each 
preceeded  by  a  milestone  or  other  decision 
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point,  during  which  a  system  goes  through 
research,  development,  test  and  evaluation  and 
production.  The  phases  are  (1)  Concept 
Exploration  &  Definition,  (2)  Demonstration  & 
Validation,  (3)  Engineering  &  Manufacturing 
Development,  (4)  Full  Rate  Production  & 
Deployment,  and  (5)  Operations  Supoort. 

Acquisition  Logistics  -  Process  of 
systematically  identifying  and  assessing 
logistics  alternatives,  analyzing  arxf  resoivirtg 
logistics  deficiencies,  and  managing  integrated 
logistics  support  throughout  the  acquisition 
process. 

Acquisttion  Managers  -  Persons  responsible  at 
differertt  levels  for  some  activity  of  developing, 
producing  and  fielding  a  weapon  system. 
Includes  senior  level  managers  responsible  for 
ultimate  decisions,  program  managers,  and 
commodity  or  functional  area  managers. 

Acquisition  Plan  (AP)  -  A  document  which 
identifies  milestones  and  addresses  all 
technical,  business  and  other  significant 
management  considerations  that  will  control  the 
acquisition.  It  is  the  principal  written 
management  document  used  to  support  the 
contracting  process.  It  records  program 
decisions,  contains  the  requirement,  provides 
^ropriate  analysis  of  technical  options  and  the 
life  cycle  plans  for  development,  production, 
training  and  support  of  material  items.  Required 
by  the  Federal  Acquisition  Regulation  (FAR). 

Acquisition  Planning  •  The  process  by  which 
the  efforts  of  all  personnel  responsible  for  an 
acquisition  are  coordinated  and  integrated 
through  a  comprehensive  plan  for  fulfilling  the 
need  in  a  timely  manner  and  at  a  reasonable 
cost.  It  is  performed  throughout  the  life  cycle 
and  includes  developing  an  overall  acquisition 
strategy  for  managing  the  acquisition  and  a 
written  acquisition  plan. 

Acquisition  Program  -  A  directed  effort  funded 
either  through  procurement  appropriations, 
through  the  S^rity  Assistance  Program,  or  the 
Research  Development  Test  &  Evaluation 
(RDT&E)  appropriation  with  the  goal  of 
providing  a  new  or  improved  capability  in 
response  fo  a  validate  need.  An  acquisition 
program  niay  include  either  development  or 
procurement  of  system,  subsystems, 
equipment,  munitions,  or  modification  to  them, 
as  well  as  supporting  equipment,  systems. 


projects,  and  studies.  Excluded  from  this 
definition  and  from  the  regulation  are  general 
purpose,  commercially  available  automatic  data 
processing  assets. 

Acquisition  Program  Baseline  (APB)  - 

Documents  the  cost,  schedule,  and  performance 
baseline  agreement  between  the  milestone 
decision  authority  and  project  team  or 
designated  component  official. 

Acquisition  Risk  -  The  chance  that  some 
elemertt  of  an  acquisition  program  produces  an 
unintended  result  with  an  adverse  effect  on 
system  effectiveness,  suitability,  cost,  or 
availability  for  deployment. 

Acquisition  Strategy  -  A  business  and 
technical  management  approach  designed  to 
achieve  program  objectives  within  the  resource 
constraints  imposed.  It  is  the  framework  for 
planning,  directing,  and  managing  a  program.  It 
provides  a  master  schedule  for  research, 
development,  test,  production,  fielding,  and 
other  activities  essential  for  program  strategies 
(e.g..  Test  and  Evaluation  Master  Plan, 
Acquisition  Plan,  competition,  prototyping,  etc.) 

Acquisition  Strategy  Panel  (ASP)  •  The  ASP 
reviews  the  integrated  program  acc^isition 
strategy  for  realism,  flexibility,  risk, 
responsiveness  to  the  user,  overall  balance,  and 
executability.  It  approves  or  recommends 
approval  of  the  acquisition  strategy  and 
commitment  of  resources  to  the  appropriate 
decision  authorities.  The  ASP  will  not  review 
implementation  details  (e.g.,  contract  terms  and 
conditions).  These  details  are  the  Program 
Office  staff  responsibility.  The  ASP  will  be 
comprised  of  Strategic  and  Tactical  Roundtable 
(see  lASP)  members  selected  by  the  Cognizant 
Program  Decision  Authority  and  the 
Center/Laboratory  Commander  who  will  jointly 
chair  the  ASP. 

Acquisition  Strategy  Report  (ASR)  - 

Describes  the  acquisition  ajforoach  to  include 
streamlining,  sources,  competition,  arfo  contract 
types  throughout  the  period  from  the  beginning 
of  Phase  I,  Demonstration  and  Validation, 
through  the  end  of  production.  As  f)art  of  the 
Integrated  Program  Summary  (IPS),  it 
summarizes  the  entire  planned  program 
structure. 
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Action  Offlotr  -  The  person  responsibie  for 
taking  action  on  a  pro^,  for  coordination  of  all 
staff  activities,  and  assembling  the  action 
package  for  decision  by  higher  authority. 


Advanced  Technology  Transition 
Demonstrations  -  Projects  within  the  6.3A 
program  which  are  intended  to;  (1)  reduce  risk 
by  proof  of  principle  demonstrations  ki  an 
operational  environment;  (2)  significantly 
enhance  capabilities  or  cost  effectiveness:  (3) 
permit  potential  user  (operator)  participation  in 
thepix^ram;  and  (4)  be  large  enough  ($10- 
1 00  million)  to  provide  a  significant  database. 


Affordability  -  A  determination  that  the  life- 
cycle  cost  of  an  acquisition  program  is  in 
consonarKe  with  the  long-range  investment  ^nA 
force  structure  plans  of  the  Department  of 
Defense  or  individual  DoD  Components. 


AFMC  Mission  Assignment  Process  - 

Established  to  ensure  all  the  taskings  which 
come  imo  the  command  are  accomplished  by 
the  most  capable  and  qualified  organization. 
This  process  is  in  the  early  stages  of  evolution. 
The  draft  is  dated  1 0  Feb  93  and  does  not  yet 
have  a  Policy  Directive  numerical  identifier. 


Air  Force  Acquisition  Model  (AFAM)  - 

Acquisition  rrx^l/database,  that  represents  the 
AF  Acquisition  process  from  pre-milestone  0  to 
po^  deployment.  It  links  processes  and 
activKies  to  factual  program  data  and  expert 
comments.  The  AFAM  software  is  an  AFMC 
managed,  PC-based,  acquisKion  management 
tool  which  describes  the  basic  system 
acr^isition  process  down  to  a  practical  level  of 
definition.  Information  can  be  assessed  related 
to  task  descriptions,  references,  lessons 
learned,  best  practices,  nominal  timeline,  etc. 
The  software  is  available  at  no  charge  to 
requesting  Government  organizations.  POC  is 
ASC/CYML,  DSN  785-3454. 


Air  Force  Planning  Guidance  (AFPG)  - 
Results  of  the  Air  Force  Defense  Planning  are 
published  in  the  AFPG  in  the  summer  of  even- 
numbered  years.  It  includes  a  summary  of  the 
Air  Force  executive  guidance,  fiscally- 
constrained  force  structure  levels  and 
assessments  of  forces.  The  AFPG  provides  the 
link  between  Defense  Planning  Guidance  (DPG) 
planning  priorities,  fiscal  reality  and  potential  Air 
Force  programs.  The  AFPG  provides  the 


strategic  inputs  to  the  Mission  Area  Assessment 
‘strategy-to-task*  process. 


Air  Force  Systems  Acquisition  Review 
Council  (AFSARC)  -  The  Air  Force  corporate 
body  that  advises  the  Air  Force  Acquisition 
Executive  (AFAE)  on  matters  concerning 
initiation,  continuation,  or  substantial  changes  to 
major  defense  program. 


AltenMtives  -  A  choice  limited  to  one  of  two  or 
more  possibilities.  Can  be  called  an  option. 


Approved  Programs  -  The  technical  and 
operational,  schedule,  and  quantity 
requirements  reflected  in  the  latest  approved 
Ac^isition  Decisbn  Memorandum  and 
Decision  Coordinating  Program  or  in  any  other 
document  reflecting  a  more  current  decision  of 
the  Secretary  of  Defense  or  other  appropriate 
approval  authority  (such  as  the  President's 
budget  and  supporting  documentation). 
Changes  being  considered  and  reflected  in 
Program  Planning  arvf  Budgeting  System 
memoranda,  such  as  Program  Objective 
Memorandums  (POMs),  Program  Decision 
Memorandums  (PDMs),  and  Program  Budget 
Decisions,  may  not  be  reported  until  approved 
and  included  in  the  President's  budget. 


Assessmern  Report  -  The  report  generated  by 
an  independent  assessment  of  a  majo»'  system 
during  any  phase  of  the  acquisition  and  support 
process  to  provide  an  examination  and 
evaluation  of  technical  requirements,  status 
toward  achievement  of  those  requirements, 
identify  problems  and  problem  causes  and 
make  recommendations  for  correction. 


Automated  Lessons  Learned  Capture  and 
Retrieval  System  (ALLCARS)  Software  - 

Database  of  lessons  learned  maintained  by 
ASC/CYM  at  Wright-Patterson  AFB  OH.  See 
Lessons  Learned  Database. 


Automated  Test  Planning  System  (ATPS)  -  A 
software  program  developed  by  OSD  that  aids 
in  the  review  of  a  test  and  eva^ation  master 
plan  prior  to  submittal  to  OSD  for  approval. 


Award  -  Notification  to  bidder  of  acceptance  of 
bid. 


Baseline  -  Defined  quantity  or  quality  used  as 
starting  point  for  subsequent  efforts  and 
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progress  measurement.  See  Performance 
Measurement  Baseline.  Can  be  program 
baseline,  technical  baseline  or  cost  baseline. 

Baseline  Conce|>t  Oescription  (BCD)  - 
Documents  Concept  configurations  and  used  as 
a  basis  to  assess  each  con^t  for  Mission 
Need  Statement  (MNS)  satisfaction. 

Baseline  Cost  Estimate  -  A  detailed  estimate 
of  acquisition  and  ownership  costs  normally 
required  for  high  level  decisions.  This  estimate 
is  performed  early  in  the  program  and  serves  as 
the  basepoint  for  all  subsequent  tracking  and 
auditing  purposes. 

Best  and  Final  Offer  (BAFO)  -  Upon 
completion  of  discussions  during  a  conventional 
source  selection,  the  contracting  offices  shall 
issue  to  all  offerors  still  within  the  competitive 
range  a  request  for  best  arxi  final  offers. 
Following  evaluation  of  the  BAFOs,  the  Source 
Selection  Authority  (SSA)  shall  select  that 
source  whose  BAFO  is  most  advantageous  to 
the  Government. 

Biennial  Planning  Programming  Budgeting 
System  (BPPBS)  •  See  PPBS 

Budget  -  A  plan  of  operations  for  a  fiscal  period 
in  terms  of  (a)  estimated  cost,  obligations,  and 
expenditures;  (b)  source  of  funds  for  financing 
including  anticipated  reimbursements  and  other 
resources:  and  (c)  history  and  work  load  data  for 
the  projected  programs  and  activities. 

Budget  Activity  -  A  budget  activity  is  a  major 
subdivision  of  a  budget  appropriation,  generally 
in  mission  areas.  It  records  estimates  for  a 
component  function  or  activity  to  be  funded  by 
the  appropriation. 

Budget  Authority  -  Authority  provided  by  law  to 
enter  into  obligations  that  will  result  in 
immediate  or  future  outlays.  It  may  be 
classified  by  the  period  of  availability,  by  the 
timing  of  congressional  action,  or  by  the  manner 
of  determining  the  amount  available. 

Budget  Estimate  -  Cost  estimate  prepared  for 
inclusion  in  the  DoD  budget  to  support  an 
acquisition  program. 

Budget  Estimate  Submission  (BES)  -  The 

annual  Services  budget  submission  to  OSD 


showing  budget  requiremenr>  Icr  inclusion  in  the 
OoD  budget. 

Budgeting  •  The  process  of  translating 
approved  resource  requirements  into  a  funding 
profile. 

Broad  Agency  Announcement  (BAA)  -  Used 
by  agencies  to  fulfiti  their  requirements  for 
scientific  study  and  experimentation  directed 
toward  advancing  the  state-of-the-art  or 
increasing  knowledge  or  understanding  rather 
than  focusing  on  a  specific  system  or  hardware 
solution. 

Chairman's  Program  Assessment  -  Provides 
an  assessment  of  the  balance,  adequacy, 
capabilities,  and  risks  of  the  Service  Program 
Ot^ective  Memorandum  (POM),  and 
recommends  actions  to  improve  overall  defense 
capability  within  OSD  fiscal  guidance. 

Chainnan's  Guidance  (CG)  Document  -  Final 
product  of  the  Joint  Strategy  Review  (JSR), 
which  provides  top-down  guidance  to  the  Joint 
Staff  and  information  to  OSD,  CINCs  and  other 
members  of  the  JCS  regarding  the  framework 
for  building  the  National  Military  Strategy 
Document  (NMSD). 

Commerce  Business  Daily  (CBD)  -  Publication 
of  Department  of  Commerce  in  which 
government  publicizes  potential  acquisitions  (a 
"synopsis")  to  notify  interested  vendors. 

Commercial  Off-The-Shelf  (COTS)  -  A 
commercial  product  (hardware  or  software) 
developed  and  produced  for  the  general  public 
having  U.  S.  Government  applicability  arid  use 
without  major  nxxfification  or  change. 

Component  Cost  Analysis  (CCA)  -  Documents 
the  Air  Force  independent  life-cycle  cost 
estimate. 

Component  Program  -  A  major  defense 
acquisition  program  delegated  to  the  Service 
Secretary  for  management. 

Comptroller  -  The  chief  financial  manager  for 
the  activity  to  which  assigned.  At  OSD  level, 
the  DoD  comptroller  is  responsible  for  the 
Planning,  Programming,  Budgeting,  System 
(PPBS)  and  all  budgetary  matters. 
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•  The  totality  of 
computer  hardware,  firmware,  software, 
personnel,  documentation,  supplies,  services, 
and  support  services  applied  to  a  given  effort. 

Computer  Resource  Life  Cycle  Management 
Plan  (CRLCMP)  -  The  primary  program 
management  dc^ment  that  de^ribes  the 
development,  acquisition,  test,  and  support 
plans  for  computer  resources  integral  to,  or  used 
in,  direct  support  of  systems. 

Concept  Action  Group  (CAG)  •  A  group 
established  and  led  by  the  Operating  Command 
during  Phase  0  activities  (CorKept  Exploration 
and  Definition)  to  manage  concept  studies  arxi 
Cost  and  Operational  Effectiveness  Analysis 
(COEA)  preparation.  The  major  command 
determines  the  composition  of  the  CAG. 

Concept  Alternatives  Review  (CAR)  -  A 

comprehensive  integrated  activity  that  is 
conducted  to  examine  the  systems  analysis 
products  for  each  concept  alternative  uiider 
consideration. 

Concept  Exploration  and  Definition  Phase  • 

Beginning  at  Program  Initiation,  the  initial  phase 
of  the  system  acquisition  process.  During  this 
phase,  the  acquisition  strategy  is  developed, 
system  alternatives  are  proposed  and 
examined,  and  the  systems  program 
requirement  document  is  expanded  to  support 
subsequent  phases. 

Concept  of  Operations  (CONORS)  -  A  verbal 
or  graphic  statement,  in  broad  outline,  of  a 
commander's  assumptions  or  intent  in  regard  to 
an  operation  or  series  of  operations.  The 
concept  of  operations  frequently  is  embodied  in 
campaign  plans  and  operation  plans;  in  the 
latter  case,  particularly  when  the  plans  cover  a 
series  of  connected  operations  to  be  carried  out 
simultaneously  or  in  succession.  The  concept  is 
designed  to  give  an  overall  picture  of  the 
operation.  It  is  included  primarily  for  additional 
clarity  of  purpose.  Frequently  it  is  referred  to  as 
the  commander's  concept  (Joint  Publication  1- 
02). 

Congressional  Budget  -  The  budget  as  set 
forth  by  Congress  in  a  concurrent  resolution  on 
the  budget.  These  resolutions  shall  include;  (a) 
the  appropriate  level  of  total  budget  outlays  and 
total  new  budget  authority;  (b)  an  estimate  of 


budget  outlays  and  new  budget  authority  for 
each  major  furtdional  category,  for 
contingencies,  and  for  other  categories;  (c)  the 
arTX)unt  of  the  surplus  or  deficit  in  the  budget  (if 
any);  (d)  the  recommended  level  of  federal 
revenues;  and  (e)  the  ajapropriate  level  of  the 
public  debt. 

Cooperativs  Opportunities  Document  (COD) 

-  Summarizes  the  results  of  the  cooperative 
opportunities  analysis  to  allow  decision  makers 
to  assess  whether  or  not  to  stoicture  a  program 
as  a  cooperative  development  program.  The 
cooperative  development  program  considers 
buying  allied  systems  or  cooperating  between 
our  various  allies  on  development,  before 
initiation  of  a  new  acquisition  program. 

Communicatiorts  Security  (COMSEC)  -  The 
protection  resultirrg  from  all  measures  designed 
to  deny  unauthorized  persons  information  of 
value  which  might  be  derived  from  possession 
and  study  of  telecommunications  or  to  mislead 
unauthorized  persons  in  their  interpretation  of 
results  of  such  possession  and  study. 

Constant  Year  Dollars  -  A  method  of  relating 
dollars  in  several  years  by  reoxiving  the  effects 
of  inflation  and  showing  all  dollars  at  the  value 
they  would  have  in  a  selected  base  year. 

Cost  Account  -  A  management  cr « frol  point  at 
which  actual  costs  can  be  accumulated  and 
compared  to  budgeted  cost  for  work  performed. 
A  cost  account  is  a  natural  control  point  for 
cost/schedule  planning  and  control,  since  it 
represents  the  work  assigned  to  one  responsible 
organization  element  on  the  contract  work 
breakdown  structure  element. 

Cost  Accounting  -  A  system  of  accounting 
analysis  and  reporting  on  costs  of  production  of 
goods  or  services,  or  of  operation  of  programs, 
activities,  functions  or  organizational  units.  The 
system  may  also  embrace  cost  estimating, 
determination  of  cost  standards  based  on 
engineering  data,  and  comparison  of  actual  and 
standard  costs  for  the  purpose  of  aiding  cost 
control. 

Cost  Analysis  -  A  process  employed  to  develop 
or  assess  the  reasonableness  and  validity  of 
resource  requirement  estimates  for  military 
systems  and  programs.  This  process  includes  a 
statement  or  report  of  the  assessment  together 
with  related  conclusions. 
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Cost  Analysis  bnprovsmsnt  Group  (CAIG)  - 
An  OSD  advisory  body  established  to  advise  the 
Defense  Systems  Acquisition  Review  Council 
(DSARC)  on  all  matters  concerning  the 
estimation,  review  and  presentation  of  cost 
analysis  of  future  weapon  systems.  The  CAIG 
also  develops  common  cost  estimating 
procedures  for  DoD.  The  CAIG  senres  as  the 
Air  Force  group  tasked  to  review  the  Cost  and 
Operational  Effectiveness  Analysis  (COEA),  the 
Program  Office  Estimate  (POE),  and  the 
Component  Cost  Analysis  (CCA)  which  formerly 
was  known  as  the  Ind^ndent  Cost  Estimate 
(ICE),  and  the  Independent  Cost  Analysis  (ICA). 
In  addition,  the  CAIG  develops  the  Air  Force 
sen/ice  cost  position,  an  adcftional  estimate 
which  reflects  the  position  of  Secretary  of  the 
Air  Force. 

Cost  Analysis  Requiremerrts  Description 
(CARD)  -  The  CARD  (as  a  part  of  the 
requirement  for  a  program  office  estimate 
(POE)  and  a  Component  cost  analysis  (CCA))  is 
established  as  a  basis  for  the  cost-estimating  of 
an  acquisition  program.  It  contains  a  description 
of  the  salient  features  of  the  program  and  of  the 
system  being  acquired. 

Cost  and  Operational  Effectiveness  Analysis 
(COEA)  -  The  quantitative  documentation  of  an 
examination  of  alternative  prospective  systems 
for  the  purpose  of  identifying  the  preferred 
system  for  eliminating  a  mission  deficiency  and 
its  associated  equipment  and  organizations. 

The  examination  aims  at  finding  more  precise 
answers  to  a  question  and  not  at  justifying  a 
conclusion.  The  analytical  process  includes 
tradeoffs  among  alternatives,  the  measurement 
of  the  effectiveness,  and  the  cost  of  the 
alternatives. 

Cost  Effectiveness -(1)  A  comparative 
evaluation  derived  from  analysis  of  alternatives 
(actions,  methods,  approaches,  equipment, 
combinations,  etc.)  in  terms  of  the  interrelated 
influences  of  cost  and  effectiveness  in 
accomplishing  a  specific  mission.  (2)  A  cost- 
effective  balance  rrxjst  be  achieved  among 
acquisition  costs,  ownership  costs  of  major 
systems,  and  system  effectiveness  in  terms  of 
the  mission  to  be  performed. 

Cost  Estimate  -  A  result  or  product  of  an 
estimating  procedure  which  specifies  the 
expected  dollar  cost  required  to  perform  a 


stipulated  task  or  to  acquire  an  item.  A  cost 
estimate  may  constitute  a  single  value  or  a 
range  of  values. 

Contract  Data  Requirements  List  (CDRL)  -  A 
list  of  data  requirements  that  are  authorized  for 
a  specific  acquisition  and  made  a  part  of  the 
contract. 

Contract  Work  Breakdown  Structure  -  The 

complete  Work  Breakdown  Structure  (WBS)  for 
a  contract,  developed  and  used  by  a  contractor 
within  the  guidelines  of  MIL-STD-%1  A,  and  in 
accordance  with  the  contract  statement  of  work. 

Critical  Intelligence  Parameters  (CfPs)  -  A 
threat  capability  or  threshold  est£d>lished  by  the 
program,  changes  to  which  could  critically, 
impact  the  effectiveness  and  sunrivability  of  the 
proposed  system. 

Defense  Acquisition  Board  (DAB)  -  The  senior 
DoD  acquisition  review  board  chaired  by  the 
Urwjer  Secretary  of  Defense  for  Acquisition. 

The  Vice  Chairman  of  the  Joint  Chiefs  of  Staff 
is  the  Vice-Chair.  Other  members  of  the  Board 
are  the  Deputy  Under  Secretary  of  Defense  for 
Acquisition  ,  Service  Acquisition  Executives  of 
the  Army,  Navy,  and  Air  Force;  the  Director  of 
Defense  Research  and  Engineering;  the 
Assistant  Secretary  of  Defense  for  Program 
Analysis  and  Evaluation;  the  Comptroller  of  the 
Department  of  Defense;  the  Director  of 
Operational  Test  and  Evaluation,  the 
appropriate  Defense  Acquisition  Board 
Committee  Chair,  and  the  Defense  Acquisition 
Board  Executive  Secretary.  Other  persons  may 
attend  at  the  invitation  of  the  Chair. 

Defense  Acquisition  Board  (DAB)  Committee 

-Advisory  review  groups  subordinate  to  the 
DAB.  The  number  of  Committees  is  determined 
by  the  Under  Secretary  of  Defense  for 
Acquisition.  The  purpose  of  the  Committee  is  to 
review  DoD  O>mponent  programs  prior  to  a 
DAB  review  in  order  to  make  an  independent 
assessment  and  recommendation  to  the  Board 
regarding  the  program. 

Defense  Acquisition  Executive  (DAE)  -  The 
principal  advisor  to  the  the  Secretary  of  Defense 
(SECDEF)  on  all  matters  pertaining  to  the  DoD 
acquisition  system  and  programs.  The  Under 
Secretary  of  Defense  for  Acquisition  (USD(A))  is 
the  DAE. 
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Dtfanae  AequisNion  Commandsr  (DAC)  -  The 
individual  who  functions  as  the  program 
executive  officer  (PEO)  on  programs  that  are 
not  assigned  to  a  PEO.  The  commanders  of 
product  divisions  and  air  logistics  centers  act  in 
this  capacity.  DACs,  like  PEOs,  are 
accountable  to  the  Air  Force  Acquisition 
Executive  (AFAE). 

Defense  Guidance  -  Document  issued  annually 
(January)  by  the  Secretary  of  Defense 
(SECDEF)  to  DoD  comporrents  providing 
strategic  framework  for  the  Program  Objective 
Memorandum  (POM). 

Defense  Planiring  arnf  Resource  Board 
(DPRB)  -Senres  as  the  corporate  review  body 
for  the  Secretary  of  Defense  (SECDEF) . 

Defense  Intelligence  Agertcy  (DIA) 
Intelligence  Report  -  Validates  the  basis  for  the 
threat  in  the  Mission  Need  Statement  (MNS) 
and  the  System  Threat  Assessment  Report 
(STAR). 

Defense  Planning  Guidance  (DPG)  -  Outlines 
OSD's  strategic  plan  for  the  development  and 
employment  of  future  forces  and  is  issued  in 
late  fall  of  odd-numbered  years. 

Defense  Systems  Acquisition  Review 
Council  (DSARC)  -  A  high  level  advisory  group 
establish^  by  and  functioning  for  the  Secretary 
of  Defense  to  appraise  the  Secretary  of  Defense 
of  the  program  status  and  readiness  of  each 
major  defense  system  to  proceed  to  the  next 
phase  in  the  acquisition  process. 

Deficiency  -  Operational  need  minus  existing 
and  planned  capability.  The  degree  of  inability 
to  successfully  accornplish  one  or  more  mission 
tasks  or  functions  required  to  achieve  mission  or 
mission  area  objectives.  Deficiencies  might 
arise  from  changing  mission  objectives, 
opposing  threat  systems,  changes  in  the 
environment,  obsolescence,  or  depreciation  in 
current  military  assets. 

Deficiency  Analysis  -  Evaluation  of  the  Air 
Force's  ability  to  accomplish  identified  tasks  and 
missions  using  current  and  programmed  future 
forces. 

Demonstration  and  Validation  Phase  -  Known 
as  Phase  I  in  the  acquisition  process,  following 


Milestone  I.  Consists  of  steps  necessary  to 
resolve  or  minimize  logistics  problems  identified 
during  concept  exploration,  verify  preliminary 
design  and  engineering,  accomplish  necessary 
planning,  fully  analyze  trade  off  proposals,  and 
prepare  contracts.  The  objective  is  to  validate 
the  choice  of  alternatives  and  to  provide  the 
basis  for  determining  whether  or  ncH  to  proceed 
irtto  Engineering  and  Manufacturing 
Development  (EMD). 

Devetopmenl  Test  and  Evalualion  (DT&E)  - 
That  test  and  evaluation  corxfucted  to  measure 
progress,  and  to  assist  the  engineerfog  design 
and  devetopmenl  process  and  verify  attainment 
of  technical  performance  specifications  and 
objectives. 

DoD  Components  -  The  Office  of  the  Secretary 
of  Defense:  the  Military  Departments;  the 
Chairman,  Joint  Chiefs  of  Staff  and  Joint  Staff; 
the  Unified  and  Specified  Commands;  the 
Defense  Agencies;  and  DoD  Field  Activities. 

DoD  Component  Acquisition  Executive  -  A 
single  official  wrthin  a  DoD  Component  who  is 
responsible  for  all  acquisition  functions  within 
that  Component.  This  includes  Service 
Acquisition  Executives  for  the  Military 
Departments  and  Acquisition  Executives  in 
other  DoD  Components  who  have  acquisition 
management  responsibility. 

Draft  Request  for  Proposal  (DRFP)  -  A  tool 
used  in  competitive  acquisitions  to  obtain 
industry  feedback  on  the  planned  acquisition. 
The  DRFP  helps  to  produce  a  more  effective 
Request  for  Proposal  (RFP)  and  a  better 
contract  by  allowing  industry  time  to  comment 
on  the  RFP  before  it  is  finalized. 

Electronic  Bulletin  Board  -  A  data  base  that 
can  be  accessed  by  industry  utilizing  standard 
modems  over  common  carrier  telephone  lines. 

It  can  be  used  to  index  library  information, 
upload  essential  documents  or  provide 
information  in  an  expeditious  manner. 

Engineering  and  Manufacturing 
Development  (EMD)  Phase  -  Known  as  Phase 
It  in  the  acquisition  process,  following  a 
Milestone  II  decision.  The  objectives  of  the 
EMD  phase  are  to  translate  the  most  promising 
design  approach  developed  in  Phase  I, 
Demonstration  and  Validation,  into  a  stable. 
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produdbie  and  cost  ettactive  system  design, 
validate  the  manufacturing  or  production 
process,  and  demonstrate  through  testing  that 
the  system  capabilities  meet  contract 
specification  requirements,  and  satisfy  the 
mission  need  and  meet  minimum  acr^abie 
operational  performance  requirements. 

Environment  -  Used  as  a  general  reference, 
environment  includes  the  generic  natural 
environment;  e.g.,  weather,  climate,  ocean 
conditions,  terrain,  vegetation,  etc.  Modified 
environment  can  refer  to  specific  induced 
environments;  e.g.,  'dirty*  battlefield 
environment,  nuclear-chemical-biological 
environment,  etc.  Environment  includes  those 
conditions  obsenred  by  the  system  during 
operational  use,  stand-by,  maintenance, 
transportation,  and  storage. 

Exit  Criteria  -  Program  specific 
accomplishments  that  must  be  satisfactorily 
demonstrated  before  an  effort  or  program  can 
progress  further  in  the  current  acquisition  phase 
or  transition  to  the  next  acquisition  phase.  Exit 
criteria  may  include  such  factors  as  critical  test 
issues,  the  attainment  of  projected  growth 
curves  arxf  baseline  parameters,  and  the  results 
of  risk  reduction  efforts  deemed  critical  to  the 
decision  to  proceed  further.  Exit  criteria 
supplement  minimum  required 
accomplishments  and  are  specific  to  each 
acquisition  phase. 

Flow  Chan  -  A  graphical  explanation  of  a 
particular  process. 

Grassroots  Working  Group  -  An  aggregation 
of  working  level  personnel  brought  together  to 
accomplish  an  assigned  task. 

Guidance  Update  Memorandum  (GUM)  - 
Addresses  any  major  questions  left  unanswered 
from  the  Defense  Acquisition  Board  required 
documentation  review.  It  identifies  major 
deficiendes  and  issues  regarding  the 
documentation.  The  information  is  used  by  the 
project  director  to  update  the  documents. 

Human  Systems  Integration  (HSI)  -  The  Air 
Force  implements  HSI  through  the  Integrated 
Mai^wer,  Personnel,  and  Comprehensive 
Training  and  Safely  (IMPACTS)  Program  Plan 
(IPP)  and  the  Preliminary  IMPACTS  Program 
Plan.  The  IPP  is  the  implementation  of  DoD 


in^ruction  5000.2,  Part  7,  Section  B, 
requirement  for  every  defense  acquisition 
program  to  develop  an  HSI  Ptavi.  It  is  also  the 
backgroutKf  amly^  and  justificalion  forthe 
manpower  Estimate  Report  (MER). 

MPACTS  -  DoOl  5000.2,  Part  7,  Section  B. 
requires  that  human  consideraiions  be 
irkegrated  into  the  design  of  defense  systems  in 
order  to  focus  on  the  capabilities  and  iimitations 
of  the  airman  in  order  to  improve  total  system 
performance  and  reduce  costs  of  ownership. 

The  Air  Force  initiative  to  incorporate  Human 
Systems  Integration  (HSI)  into  Air  Force  weapon 
si^em  programs  is  called  IMPACTS.  The 
IMPACTS  program  is  a  comprehensive 
management  and  technical  approach  for 
addressing  the  human  centered  elements  of 
manpower,  personnel,  training,  safety,  health 
hazards,  and  human  factors  engineertog  in  the 
acquisition  of  new  or  improved  systems. 

IMPACTS  Planning  Team  -  The  Integrated 
Manpower,  Personnel  and  Comprehensive 
Training  and  Safety  (IMPACTS)  Planning  team 
brings  together  the  necessary  expertise  required 
to  assess  and  address  issues  within  individual 
IMPACTS  elements,  such  as  manpower, 
personnel,  training,  and  safety  constraints,  and 
to  provide  a  forum  for  assessing  tradeoffs.  Up 
to  Milestone  0,  this  process  is  meant  to  be  very 
approximate  and  non  time-consuming  because 
of  the  lack  of  specificity  associated  with  the 
Mission  Need  Statement  process.  After 
Milestone  0,  a  more  in-d^h  analysis  wiM  be 
required. 

Implementation  -  The  publication  of  directives, 
ir^troctions,  regulations,  and  related  documents 
that  define  responsibilities  and  authorities  and 
establish  the  internal  management  processes 
necessary  to  implement  the  policies  or 
procedures  of  a  higher  authr^. 

tanplementing  Command  -  The  command  or 
agency  designated  by  the  Air  Force  Acquisition 
Executive  to  manage  an  acquisition  program. 

Independent  Cost  Analysis  -  An  analysis  of 
program  cost  estimates  conducted  by  an 
impartial  body  disassociated  from  the 
management  of  the  program  (See  Title  10, 
United  States  Code,  Se^ion  2434, 

'IrxfeperKfent  cost  estimates;  operational 
manpower  requirements'). 
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kKtopcndtnl  Cost  Eatimalo  -  A  cost  e^imate 
prepjtfsd  by  an  impartial  body  outside  the  chain 
oi  authority  rwportsible  tor  acquiring  or  using 
goods  or  services. 

Indualry  Link  -  The  government  establishes  a 
link  with  industry  to  obtain  the  latest 
technological  information  in  support  of  Air  Force 
deficiencies.  Participation  in  early  study  or 
mission  needs  allows  indi^ry  visibility  into 
potential  requests  tor  acquisfiion  support. 

Industry  Preaollcitatlon  Confeienoe  -  A 
method  of  conveying  information,  ertoancing 
understanc^  of  requirements,  reducing 
adversarial  relationships  and  building  a  sense  of 
ownership  in  the  program  from  both  the 
governrnent  and  industry  standpoint.  Industry 
conferences  must  be  published  in  the 
Commerce  Business  Daily  (CBO)  to  facilitate 
industry  wide  participation. 

lirtegtetod  Acquisition  Strategy  Process 
(lASP)  'The  lASP  is  a  program  nrutnagement 
orient^,  *top<town*  process  which  irKX>rporates 
the  input  of  senior  experienced  advisors  early  in 
the  formulation  of  the  acquisition  strategy.  To 
accomplish  this,  senior  leaders  and  functional 
experts  meet  in  a  series  of  ’Roundtable' 
discussions  with  the  System  Program 
Ohrector/Laboratory  Program  Manager/Initial 
Program  Office  Cadre  (referred  to  in  the 
process  guide  as  project  manager/project  team) 
to  provide  timely  advice  on  acquisition 
strategies  to  achieve  program  goals.  The  full 
lASP  includes;  (1)  Strategic  Roundtable,  (2) 
Tactical  Roundtable,  (3)  Acquisition  Strategy 
Panel,  and  (4)  Operational  Roundtable. 

Integrated  Logistics  Support  (ILS)  -  A 
disciplined,  unified,  and  iterative  approach  to 
the  management  and  technical  activities 
necessary  to  integrate  support  considerations 
into  system  and  equipment  design;  develop 
support  requirements  that  are  related 
consistently  to  readiness  and  provide  the 
required  support  during  the  operational  phase  at 
rrunimum  cost. 

Integrated  Logistics  Support  Pian  (iLSP)  - 

Descitoes  the  concepts,  resource  requirements, 
tasks,  schedules,  and  subordinate  plans 
associated  with  each  ILS  element.  The  ILS 
elements  encompass:  maintenance  planning, 
manpower  and  personnel,  supply  support. 


facilities,  packaging,  handling,  storage,  and 
transportation,  and  design  interface. 

totsgralsd  Product  Dsvsiopinsnt  (PD)  -  A 
philosophy  that  systematically  empi^  a 
teaming  of  functional  disciplines  to  integrate  and 
concurrently  apply  aH  necessary  processes  to 
produce  an  effective  and  efficient  product  that 
satisfies  customer  needs. 

integrated  Program  Aaaassmant  (IPA)  -  A 
document  prepared  by  the  supporting  staff  or 
review  tonjm  of  the  milestone  decision  authority 
to  support  Milestone  I,  II,  III,  and  IV  reviews,  it 
provides  an  independent  assessment  of 
program  status  and  readiness  to  proceed  into 
the  next  phase  of  the  acquisition  cycle. 

Integrated  Program  Summary  (IPS)  -  A  DoO 
Component  document  prepared  and  submitted 
to  the  milestone  decision  authority  in  support  of 
Milestone  I.  II.  III.  and  IV  reviews.  It  succinctly 
highlights  the  status  of  a  program  and  its 
readiness  to  proceed  into  the  next  phase  of  the 
acquisition  cycle. 

integrated  Weapons  System  Mansgement 
(iWSM)  -  The  AFMC  management  philosophy 
for  acquiring,  evolving,  and  sustaining  our 
products.  It  empowers  a  single  manager  with 
authority  over  tlW  widest  range  of  decisions  and 
resources  to  satisfy  customer  requirements 
throughout  the  life  cycle  of  the  product. 

totegrated  Weapon  System  Management 
Man  (IWSMP)  -  This  plan  addresses  both  the 
acquisition  phase  and  the  evolution  and 
sustainment  phase  of  a  weapon  system.  The 
IWSMP  will  define  the  weapon  s^em  evolution 
throughout  the  system  life  cycle.  It  will  be 
agreed  to  by  the  developer/supporter  and  the 
customer  and  will  allow  coordinated  budgeting 
and  tradeoffs  to  be  made  with  fuH  knowledge  of 
what  is  forecasted  for  the  future. 

Issue  a  Letter  -  Letters  are  issued  to  individual 
prospective  offerors  containing  identical 
information  to  ensure  that  no  firm  is  given  an 
unfair  advantage  as  a  result  of  government 
actions. 

Intelligence  Community  -  Defense  Intelligence 
Agency  (DIA),  National  Security  Agency  (NSA), 
Central  Intelligence  Agency  (CIA)  responsbie 
for  producing  a  wide  variety  of  (k^ments 
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addr«6Sing  threat  information  to  determine  if 
current  miMary  capebiMiee  are  sufficient  to 
meet  envisfoned  threat  scenarios. 

imeNigenee  Report  -  A  report  provided  by  the 
appropriate  inteilioence  agency/oommand  to  the 
milesfone  decision  authority  prior  to  each 
milestone  review.  For  Mil^one  0,  the  report 
will  confirm  the  validity  of  the  threat  contained  in 
the  Mission  Need  ^tement  (MN&).  For 
Milestone  I,  the  report  wil  confirm  the  validity  of 
the  system  threat  assessment  (STA)  used  in 
support  of  the  program  and  will  address  any 
threat  issues  or  unresolved  threat  concerns 
affecting  the  program. 

Invltalion  tor  Bid  -  A  solicitation  document 
used  in  sealed  bidding  acquisitions. 

Issue  Papers  -  OSO  documents  that  define 
issues  raised  as  a  result  of  the  analysis  of  the 
annual  Program  Objective  Memorandum  (POM) 
submittal  prepared  to  assist  the  Secretary  of 
Defense  in  making  Ns  decision. 

Joint  Program  -  Any  Defense  acquisition 
system,  subsystem,  component,  or  techrK>logy 
program  that  involves  formal  management  or 
funding  by  more  than  one  DoD  Component 
during  any  phase  of  a  systems  Hte-cycle. 

Joint  Requiraments  Oversight  Council 
(JROC)  -  A  Council,  chaired  by  the  Vice 
Chairman,  Joint  Chiefs  of  Staff,  that  conducts 
requirements  analyses,  determines  the  valkJfty 
of  rNssion  needs  and  develops  recommended 
joint  priorities  for  those  needs  it  approves,  and 
validsrtes  performance  objectives  and  thresholds 
in  support  of  the  Defense  Acquisition  Board. 
Council  members  include  the  Vice  Chiefs  of  the 
Army,  Navy,  and  Air  Force,  and  the  Assistant 
Cornmandant  of  the  Marine  Corps  (See  MCM- 
ITS-SO,  ’Charter  of  the  Joint  Requirements 
Oversight  Coundr). 

Joint  Requirements  Oversight  Council 
(JROC)  Assessment  -  Verifies  the  need  and 
confirms  that  the  proposed  performance 
objectives  and  thresholds  to  be  contained  in  the 
program  baseline  satisfy  the  operational  need. 

Joint  Strategic  Capabilities  Plan  (JSCP)  • 
Contains  guidance  to  the  Commanders  in  CNef 
and  Senrice  Chiefs  for  the  accomplishment  of 


miiitafy  tasks  in  the  near  term  (2  years),  given 
their  Service  capabiities  arfo  attrfoutes. 

Joint  Strategy  Review  (JSR)  •  A  process  tor 
gathering  intomnabon,  rafoing  issues,  and 
integrating  strMgy  and  operational  planning 
with  program  assessmwS. 

Joifrt  Wortcing  Group  (JWG)  •  Composed  of 
representatives  for  the  combat  and  materiel 
developers  and  appropriate  subject  matter 
experts.  The  primary  purpoM  is  to  provide  a 
forum  tor  direct  communication  facilitating  the 
coordination  of  requirements  documents. 

Lsssons  Lsamsd  Datahass  -  Air  Force 
acquis^ion  personnel  may  gain  access  to  a 
large  database  of  acquisition  lessons  learned 
through  the  PC-based  ‘Automated  Lessons 
Learned  Capture  and  Retrieval  System 
(ALLCARS)*  software.  The  database  this 
software  draws  from  is  supported  by  the  Air 
Force,  the  Army,  the  Navy,  and  the  Marine 
Corps.  PCX:  is  ASC/CYML,  DSN  785-3454. 

Life  Cycle  Cost  (LCC)  -  The  total  cost  to  the 
government  of  acquisition  and  ownership  of  a 
system  over  its  useful  Hfe.  It  includes  the  cost 
of  development,  acquisition,  support  and,  where 
applicable,  disposal. 

Logistics  Supportability  -  The  degree  to  which 
planned  logistics  support  (including  test, 
measurement,  and  diagno^ic  equipment; 
spares  and  repair  parts;  technical  data;  sup^ 
facilities;  transportation  requirements;  training; 
manpower;  and  software  support)  aNow  meeting 
system  availability  and  wartime  usage 
requrements. 

Logistic  Support  AnalyMs  (LSA)  -  The 
selective  application  of  scientific  and 
engineering  efforts  undertaken  during  the 
acquisition  process,  as  part  of  the  systems 
engineering  process,  to  assist  in:  causing 
support  considerations  to  influence  design; 
definfog  support  requirements  that  are  related 
optimally  to  design  and  to  each  other;  acqui^ 
the  required  support;  and  providing  the  required 
support  during  the  operational  phase  at 
miNmum  cost. 

Loglatica  Support  Analysis  Record  (LSAR)  - 
A  formal  tool  under  MIL-STD  1388-2A  that  uses 
recordsTtorms  to  document  operations  and 
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mainlenance  requiremems,  R&M,  task  analy^, 
techniciri  data,  support/test  equipment,  facilities, 
skii  evaluation,  su|^  support,  ATE  and  TPS. 
and  transportabWty.  LSAR  is  the  basis  for 
tracing,  personnel,  supply  provisioning  and 
allowances  construction,  support  equipmertt 
acquisition,  facilities  constnxrtion  and 
preparation,  and  for  maintenenace-preventive 
and  corrective. 

Maior  Defenae  Acquisition  Program  -  A  DoO 
acquisition  program  that  is  not  a  highly  sensitive 
classified  program  (as  detennined  by  the 
SECOEF  and  :  (a)  That  is  designated  by  the 
SECOEF  as  a  major  defense  acquisition 
program  because  of  urgency  of  need, 
development  risk,  joint  funding,  significant 
Congressional  interest,  or  other  considerations, 
or;  (b)  That  is  estimated  by  the  SECOEF  to 
require  an  eventual  total  expenditure  for 
research,  development,  test,  and  evaluation  of 
more  than  $200  million  (based  on  FY 1980 
constant  dollars)  or  an  eventual  total 
expenditure  for  procurement  of  more  than  $1 
billion  (based  on  FY  1980  constant  dollars). 

This  definition  is  based  on  the  criteria 
established  in  Title  10,  United  States  Code, 
Section  2430  "Major  Defense  Acquisition 
Programs  Defined." 

Major  Program  -  A  term  synonymous  with 
"major  defense  acquisition  program." 

Major  System  (Congressional  and  Federal 
Acquisition  Regulation  definition)  • 

Redefined  by  the  DoD  Authorization  Act,  FY  85 
(10  U.S.C.  2302);  dollar  thresholds  RDT&E  - 
$75M  plus  (in  FY  80  constant  $1 ).  Procurement 
-  $300M  plus  (in  FY  80  constant  $1 ). 

Major  System  (0MB  Circular  A-109 
Definition)  -  That  combination  of  elements  that 
will  function  together  to  produce  the  capabilities 
required  to  fulfill  a  mission  need.  The  elements 
may  include,  for  example,  hardware,  equipment, 
software,  constoiction,  or  other  programs  that 
(1)  are  directed  at  and  critical  to  fulfilling  an 
agency  mission,  (2)  entail  the  allocation  of 
relatively  large  resources,  and  (3)  warrant 
special  management  attention.  Additional 
criteria  and  relative  dollar  thresholds  for  the 
detemrxnation  of  agency  programs  to  be 
considered  major  systems  under  the  purview  of 
this  Circular,  may  be  established  at  the 
discretion  of  the  agency  head. 


Material-  (1)  Prof)erty  which  may  be 
incorporated  into  or  attached  to  an  end  item  to 
be  delivered  urtder  a  contract  or  which  may  be 
consumed  or  expended  in  the  performance  of  a 
contract.  It  includes,  but  is  not  limked  to,  raw 
and  processed  material,  p^,  components, 
assemblies,  fuels  and  lubricants  and  small  tools 
and  supplies  which  may  be  consumed  in  normal 
use  in  the  performance  of  a  contract.  (2)  The 
substance  or  substances  of  which  a  thing  is 
made  or  composed. 

Materiel  -  (1)  Military  arms,  ammunition,  and 
equipment  in  general.  (2)  The  aggregate  of 
things  used  or  needed  in  any  business, 
undertaking,  or  operation  (distinguished  from 
personnel). 

Materiel  Group  -  A  grouping  consisting  of 
several  like  products  that  normally  receive 
consolidated  management  for  sustainment 
largely  for  reasons  of  economy  of  scale  and 
specialization  of  technical/errgineering 
expertise,  e.g.,  landing  gear.  Normally  does  not 
have  any  ongoing  developmental  efforts. 

Materiel  Group  Manager  (MGM)  -  The 
individuat  managing  an  AFMC  Materiel  Group 
who  is  ultimately  responsible  and  accountable 
for  decisions  and  resources  in  overall  materiel 
group  management.  The  MGM  is  the  single 
person  who  is  charged  with  all  cost,  schedule, 
and  performance  aspects  of  a  materiel  group. 
The  MGM's  primary  customers  for  the  daily 
sustainment  products  and  sen/ices  and  new 
equ^>ment  are  the  using  MAJCOMs.  However, 
the  MGM's  customers  for  integration  of  new 
development  and  technology  transition  are  the 
respective  project  managers  and  system 
program  directors. 

Memorandum  of  Agreement  -  (1 )  In  contract 
administration,  an  agreement  between  a 
program  manager  and  a  (^tract  Administration 
Office  (CAO),  establishing  the  scope  of 
responsibility  of  the  CAO  with  resf^  to  the 
Cosf/Schedule  Control  Systems  Criteria 
(C/SCSC)  surveillance  functions  and  objectives, 
and/or  other  contract  administration  functions  on 
a  specific  contract  or  program.  (2)  Any  written 
agreement  in  principle  as  to  how  a  program  will 
be  administered. 

Milestone  -  The  point  when  a  recommerxfation 
is  made  and  approval  sought  regarding  starting 
or  continuing  (proceeding  to  next  phase)  an 
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acquisition  program.  Milestones  are;  0 
(Concept  Direction),  I  (Concept  Approval),  II 
(Engineering  and  Manufacturing  D^eloprrient), 
III  (Production  Approval),  and  IV  (Ma^ 
Upgrade  Decision). 

MHeetone  Decision  Authority  (MOA)  -  The 
individual  designated  in  accordance  with  criteria 
established  by  the  Under  Secretary  of  Defense 
for  Acquisition  (USD(A))  to  approve  entry  of  an 
acquisition  program  into  the  next  phase. 

Milestone  I  Program  C  jsl  EMimate  -  This  will 
be  the  formal  Life  Cycle  Cost  (LCC)  estimate  tor 
the  program  altemative  that  will  be 
recommended  tor  approval  at  the  Milestone  I 
Decision  Review.  The  estimate  should  include 
all  program  Nfe  cycle  costs;  development, 
production,  operating  and  support,  and  disposal. 

Military  Capability  -  A  measure  of  military 
systems  ability  to  achieve  the  mission 
objectives,  given  the  system  condition  during 
the  mission. 

Military  System  -  A  discrete,  stand-alone 
system  or  collection  of  systems  and  related 
resources  which,  in  conjunction  with  user 
support  and  operation,  provide  a  capability  to 
accomplish  a  specific  military  mission,  e.g.,  F- 
22  or  Global  Positioning  Systems  (GPS). 

Minimum  Required  Accomplishments  - 
Necessary  tasks  that  must  be  completed  during 
an  acquisition  phase  prior  to  the  next  miiestone 
decision  review.  Applies  to  all  acquisition 
categories  and  highly  sensitive  classified 
programs. 

Mission  -  The  objective  or  task,  together  with 
the  purpose,  which  clearly  indicates  the  action 
to  be  taken. 

Mission  Area  -  A  segment  of  the  defense 
mission  as  established  by  the  Secretary  of 
Defense.  Each  DoD  component  has  mission 
areas  (i.e..  Navy  -  sea  control)  tor  which  it  must 
equip  its  forces  for  potential  hesitates. 

Mission  Area  Assessment  (MAA)  -  Continuous 
analysis  of  assigned  mission  responsibilities  in 
the  several  mission  areas  to  identify  functions  or 
tasks  that  will  satisfy  mission  needs 


Mission  Ares  Plans  -  Ensures  that  adequate 
resources  (people  and  money)  are  available  to 
support  the  mission  area  planning  process. 
During  this  activity,  the  MAXOM  determines 
what  mission  area  planning  will  be  required, 
which  agencies/organizations  need  to  be 
involved  in  the  process  and  what  funding  is 
needed  to  support  any  study  and  analyses 
effort. 

Mission  Deficisnciss  -  Opwational  need  minus 
existi^  and  planned  capability.  The  degree  of 
inabil^  to  successfully  accornpiish  one  or  more 
mission  tasks  or  functions  required  to  achieve 
mission  or  mission  area  objectives. 

Deficiencies  might  arise  from  changing  mission 
objectives,  opposing  threat  systems,  changes  in 
the  environment,  obsolescence,  or  depreciation 
in  current  military  assets. 

Mission  Need  -  A  statement  of  operational 
capability  required  to  perform  mission 
operations. 

Mission  Need  Analysis  (MNA)  -  A  process 
designed  to  assess  the  Air  Force  ability  to 
accomplish  the  tasks  identified  durtog  Mission 
Area  Assessment  (MAA).  MNA  uses  a  task-to- 
need  methodology  to  id^tify  mission  needs. 
MNA  can  also  highlight  technological 
opportunities  and  identify  reliability  and 
maintainability  improvements  which  can  also 
enhance  warfighting  capabilities. 

Mission  Need  Statement  (MNS)  -  A  docunoent 
prepared  to  identify  a  requirement  tor  a  materiel 
solution  to  satisfy  a  mission  deficiency. 

Modification  -  A  configuration  change  to  a 
delivered  configuration  item. 

National  Military  Strategy  Document  (NMSD) 

-  Joint  Chiefs  of  Staff  (JCS)  document  that 
recommends  military  strate^  and  fiscaHy- 
constrained  force  structure  to  the  President, 
National  Security  Council,  and  Office  of  the 
Secretary  of  Defense  (OSD).  The  NMSD  is 
issued  in  the  summer  of  odd-numbered  years 
and  is  a  major  input  to  the  formulation  of  the 
OSD's  Defense  Planning  Guidance  (DPG). 

New  Start  -  A  major  defense  acquisition 
program  approved  at  milestone  0  by  a  USD(A) 
Acquisition  Decision  Memorandum  (ADM). 
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N«w  Woffc  -  A  ooiporaie  review  process  (or  some  of  which  may  conflict,  and  (4)  obiectives 


both  accepting  and  allocating  new  work  for  ASC 
Acc^isition  Organizations.  The  process  is 
designed  to  match  new  work  requirements  with 
available  resources. 

Non-0«velopinentalllem(NDI)-(1)  Any  item 
of  sr^tpiy  that  is  available  in  the  commercial 
marketplace;  (2)  Any  previously  developed 
Kem  of  supply  th^  is  in  use  by  a  department  or 
agency  of  the  U.  S.,  a  State  or  local 
government,  or  a  fcireign  govemmerk  with  which 
the  U.  S.  has  a  mutual  defense  cooperation 
agreement;  (3)  any  item  of  supply  described  in 
(1)  or  (2),  that  requires  only  minor  modification 
in  ordw  to  meet  the  requirements  of  the 
procuring  agerx^y;  or  (4)  any  Hern  of  supply 
that  is  currently  being  produced  that  does  not 
meet  the  requirements  of  definition  (1)  (2)  or  (3) 
above,  solely  because  the  item  is  not  yet  in 
use  or  is  not  yet  available  in  the  commercial 
marketplace. 

Noimajor  Defense  Acquisition  Program  •  A 

program  other  than  a  major  defense  acquisition 
program  or  a  highly  sensitive  classified 
program. 

Nonmajor  System  -  A  full  system  that  does  not 
qualify  as  a  major  system  or  performs  a  major 
function  of  a  complete  system  that  is  either 
within  a  major  or  another  nonmajor  system. 

Nuclear  Certification  Plan  -  This  plan  provides 
overall  guidance  and  policy  concerning  the 
nuclear  certification  aspects  of  the  project  (if 
applicable).  It  identifies  nuclear  certification  and 
safety  activities  that  must  be  accomplished,  and 
identifies  major  contributors  and/or 
responsibilites  of  the  participants  in  the  nuclear 
certification  and  safety  projects.  It  serves  as  an 
integrated,  cohesive  i^an  to  accomplish  the 
required  nuclear  certification  tasks.  For  plan 
procedures  see  AFR  t22-1 ,  The  Air  Force 
Nuclear  Weapon  Surety  Program  and  ASC/ENS 
Nuclear  Certification  Handbook,  Feb  87. 

Objective  -  The  target  of  an  organization  or 
system.  In  military  organizations  this  is  usually 
synonymous  with  the  mission.  A  detailed 
analysis  would  indicate  that  (1 )  at  times  it  is 
diffk^lt  to  obtain  an  explicit  statement  of  an 
organization's  ot^ectives,  (2)  objectives  will 
vary  at  different  levels  within  an  organization, 

(3)  several  objectives  will  exist  at  one  level, 


are  dynamic  and  change  wkh  time. 

Offer  -  A  response  to  a  soiidtation  that,  if 
accepted,  would  bind  the  offerer  to  perform  the 
resultant  contract. 

Office  of  the  Under  Secretary  of  Defenee 
(Acquieition)  -  The  Office  of  the  USD(A), 
OUSD(A),  is  organized  around  functional  areas 
of  services,  R&D,  and  material  acquisition. 
Seven  OSD  oiganizationat  elements  report  to 
the  USD(A):  -Director,  Defense  Research  and 
Engineering  (DDR&E)  -Assistant  Secretary  of 
Defense  (Commarxf  Control.  Communications 
and  intelligence)  (C31),  for  acquisition  matters  - 
Assistant  Secretary  of  Defense  (Production  and 
Logistics)  (ASD(P&L)  -Assistant  Secretary  of 
Defense  (Atomic  Energy)  -Director,  Program 
Integration  (PI)  -Director,  Small  and 
Disadvantaged  Business  Utilization  (SADBU)  - 
Executive  Director,  Defense  Science  Board 
(DSB).  Additionally,  the  Commandant  of  the 
Defense  Systems  Acqui£^.ion  report  to  the 
USD(A)  -Defense  Communications  Agertcy 
(DCA)  -Defense  Logistics  Agency  (DLA)  - 
Defense  Mapping  Agency  (DMA)  -Defense 
Nuclear  Agency  (DNA)  -  On  Site  Inspection 
Agency  (OSIA). 

0MB  Circular  A>109  -  As  the  President's  chief 
administrative  manager  for  the  Federal 
Government,  0MB  issued  this  directive  in  1976. 
it  defines  the  system  acquisition  process  as  "a 
sequence  of  acquisition  activities  starting  from 
the  ^ncy's  mission  needs,  with  its  capabilities, 
priorities  and  resources  (dollars),  extending 
through  introduction  into  use  or  successful 
achievement  of  program  objectives." 

Ombudsman  Program  -  Each  product  division 
establishes  an  ombudsman  to  serve  as  a 
channel  for  industry  comments  on  a 
nonattribution  basis.  The  ombudsman  is 
appointed  to  hear  and  investigate  complaints 
against  the  government. 

Operating  Command  -  The  command  primarily 
operating  a  system,  subsystem,  or  item  of 
equpment.  Generally  applies  to  those 
operational  commands  designated  by 
Headquarters,  US  Air  Force  to  conduct  or 
participate  in  operations  or  operational  testing. 
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OpMWtioniri  Aw ttm>nt  •  An  evaluation  of 
opeiational  effectiveness  and  operational 
suitability  made  by  an  independent  operational 
test  activity,  with  user  support  as  required,  on 
other  than  production  systems.  The  focus  of  an 
operational  assessment  is  on  significara  trends 
noted  in  development  efforts,  programmatic 
voids,  areas  of  risk,  adequacy  of  requirements, 
and  the  ability  of  the  program  to  support 
adequate  operational  testing.  Operational 
assessments  may  be  made  at  any  time  using 
technology  demonstrators,  prototypes, 
mockups,  engineering  development  models,  or 
simulations  but  will  not  substitute  for  the 
independent  operational  test  and  evaluation 
necessary  to  support  full  production  decisions. 

Operational  Effectiveness  •  The  overall 
d^ree  of  mission  accomplishment  of  a  system 
used  by  representative  troops  in  the  context  of 
the  organization,  doctrine,  tactics,  threat,  and 
environment  in  the  planned  operational 
employment  of  the  system. 

Operational  Reliability  and  Maintainability 
Value  -  Any  measure  of  reliability  or 
maintainability  that  includes  the  combined 
effects  of  item  design,  quality,  installation, 
environment,  operation,  maintenance,  and 
repair. 

Operational  Requirements  Document  (ORD) 

-  Identifies  minimum  acceptable  performance 
requirements  to  satisfy  the  operational  need; 
also  irx^ludes  performance  objectives  that  would 
provide  operationally  meanin^l  increases  in 
capability.  Prepared  by  user  or  user's 
representative.  DoD  5000.2M,  Part  3  contains 
preparation  procedures  and  format. 

Operational  Roundtable  III  (See  lASP)  - 

Develops  and  harmonizes  the  detailed 
functional  plans  and  milestone  directed 
documentation. 

Operational  Suitability  -  The  degree  to  which  a 
system  can  be  placed  satisfactorily  in  field  use 
with  consideration  given  to  availability, 
compatibility,  transportability,  interoperability, 
reliability,  wartime  usage  rates,  maintainability, 
safety,  human  factors,  manpower  supportability, 
logistics  supportability,  natural  environmental 
effects  and  impacts,  documentation,  and 
training  requirements. 


Operations  Security  (OPSEC)  •  A  procw  of 
analyzing  friendly  act  ons  attendant  to  military 
operations  and  other  activities  to; 

a.  Identify  those  actions  that  can  be 
observed  by  adversary  intelligence  systems. 

b.  Determine  indicators  hostile 
inteHigence  systems  might  obtain  that  could  be 
interpreted  or  pieced  together  to  derive  critical 
information  in  time  to  be  useful  to  adversaries. 

c.  Select  and  execute  measures  that 
eliminate  or  reduce  to  an  acceptable  level  the 
vulnerabiMies  of  frierKfly  actions  to  adversary 
exploitation.  Protection  of  military  operations 
and  activities  resulting  from  identification  and 
subsequent  elimination  or  control  of  indicators 
susceptible  to  hostile  operations. 

Oversight  -  Review  activity  by  cor^gressional 
committees  of  DoD  programs  to  determine  (1 ) 
status,  (2)  if  the  law  is  being  followed  or  (3) 
basis  for  possible  future  legislatbn. 

Parameter  •  A  determining  factor  or 
characteristic.  Usually  related  to  performance  in 
developing  a  system. 

Participating  Service  •  An  organization  that 
supports  the  lead  service  in  the  development  of 
a  program  by  its  contribution  of  personnel 
and/or  funds  for  the  successful  completion  of 
the  program. 

Participants  in  Defense  AcquisHlon  -  The 
three  participants  (players)  in  defense 
acquisition  are  the  Executive  Branch  of  the 
Federal  Government,  the  Legislative  Brafx:h 
and  Inckjstry  (defense  contractors).  Each  has  a 
significant  role  and  perspective. 

Performance  -  Those  operational  and  support 
characteristics  of  the  system  that  allow  it  to 
effectively  and  efficiently  perfonn  its  assigned 
mission  over  time.  The  support  characteristics 
of  the  system  include  both  supportability 
aspects  of  the  design  and  the  support  elements 
necessary  for  system  operation. 

Personnel  -  A  body  of  persons  usually 
employed  in  an  organizations.  "Faces." 
Individuals,  by  grade,  experience,  skill  levels, 
etc. 

Phases  (0  through  IV)  -  The  acquisHion  phases 
provide  a  logical  means  of  progressively 
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A. 

^  translating  broadly  stated  mission  needs  into 

and  existing  weapon  systems;  reduce  the  use  of 

• 

^  well  defined  system-specific  requirements: 

hazardous  materials  a^  waste  generation  at 

«) 

0  Conc^  Exploration  and 

installations  and  Government  Owned  Contractor 

1 

Definition 

Operated  (GOCO)  facilities;  acquire  state  of  the 

1  Demonstration  and  Validation 

art  pollution  prevention  technologies;  apply  new 

II  Engineering  and  Manufacturing 

technology  to  pollution  prevention,  from  outside 

Development 

Air  Force  research;  est^ish  investment 

III  Production  and  Deployment 

IV  Operations  and  Supped 

strategy  to  fund  pollution  prevention  program. 

(DoD  Directive  5000.1 ) 

Preferred  Alternatives  Review  (PAR)  -  A 

comprehensive  quality  review  th^  assesses  the 

» 

Planning  for  Oefenae  Acquisition  -  The 

technical  adequacy  and  scope  of  the 

process  through  which  the  national  security 

altemative(s)  including  the  interface  and 

threat  is  evaluated,  mission  needs  defined. 

operability  issues.  It  determines  whether  each 

systems  requirements  established,  resources 

of  the  primary  system  functions  have  been 

(money,  manpower  and  material)  programmed 

adequately  a^ressed  to  surface  any  subsystem 

1 

and  the  resultant  system  acquisition  program 
authorized  and  he^n.  Planning  for  acquisition, 

issues  and  to  support  system  planning. 

a  recurring  process  which  generates  a  system 
need,  precedes  acquisition  planning  for  a 
specific  program. 

Preliminary  IMPACTS  Program  Ptan  (P-IPP)  - 

IMPACTS  tasking  begins  with  Pre-Milestone  0 
development  and  documentation  of  system 

IMPACTS  goals,  constraints,  and  objectives. 

1 

Planning,  Programming,  Budgeting  System 

These  are  developed  through  a  thorough 

(PPBS)  -  An  integrated  DoD  system  for  the 

analysis  of  the  predecessor  system  or  new 

establishment,  maintenance,  and  revision  of  the 

system  concept  designs.  Th^  goals. 

Rve  Year  Defense  Program  (FYDP)  and  the 

constraints,  and  objectives,  along  with  a 

DoD  budget.  Focal  point  is  ASC  (Comptroller). 

strategy  for  meeting  them,  are  documertted  in 

First  of  four  phases  of  the  Resource  Allocation 

the  Preliminary  IMPACTS  Program  Plan  (P- 

% 

• 

•  Process.  The  purpose  of  the  PPBS  is  to:  (1 ) 

IPP). 

complete  the  defense  planning  phase,  which  in 
many  cases  began  years  before,  (2)  initiate 

Process  -  (1 )  The  combination  of  people. 

and  complete  the  programming  phase,  where 

equipment,  materials,  methods,  and 

plans  are  prioritized  and  matched  with  expected 

environment  that  prodUv..^  output-a  given 

funds,  and  (3)  result  in  a  DoD  budget  for 

product  or  service.  A  process  can  involve  any 

presentation  to  the  Congress  as  part  of  the 

aspect  of  a  business.  A  key  tool  for  managing 

1 

President's  budget.  Until  1987,  the  PPBS  was 

processes  is  statistical  process  control,  (2)  a 

an  annual  process  through  which  DoD  prepared 

planned  series  of  actions  or  operations  which 

its  annual  budget.  Beginning  in  1986  with 

advances  a  material  or  procedure  from  one 

submission  of  the  the  first  2-year  defense 

stage  of  completion  to  another,  and  (3)  a 

budget,  for  fiscal  years  1988-89,  the  PPBS 

planned  and  controlled  treatment  that  subjects 

became  a  biennial  procedure.  In  common 

materials  to  the  influence  of  one  or  more  types 

usage,  the  term  PPBS  generally  implies  the 

of  energy  for  the  time  required  to  bring  about 

resource  allocation  process. 

the  desired  reactions  or  results. 

Player  -  A  Participant. 

Procuring  Contracting  Officer  (PCO)  -  The 
individual  authorized  to  enter  into  contracts  for 

Point  of  Contact  -  Person  serving  as 

supplies  and  services  on  behalf  of  the 

coordinator,  action  officer  or  focal  point  for  an 

government  by  sealed  bids  or  negotiations  who 

activity. 

is  responsible  for  overall  procurement  of  the 
contract. 

Pollution  Prevention  ^tion  Plan  (PPAP)  -  A 
plan  to  prevent  the  release  of  pollutants  into  the 

Product  -  Product,  as  referred  to  in  the  IPD 

environment  and  reduce  the  use  of  hazardous 

Definition,  is  not  only  what  is  delivered  to  your 

a 

materials.  The  major  plan  ot^ectives  are: 

customer  (e.g.,  design,  manufacturing,  test, 

reduce  the  use  of  hazardous  materials  in  new 

logistics,  acquisition  security...)  which  make  the 

product  possible.  Products  range  from 
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compiete  weapon  systems  to  individual  end 
items,  from  request  for  proposals  to  briefings,  as 
well  as  policies  and  processes. 

Product  Group  -  A  grouping  consisting  of 
several  like  presets  in  all  life  cycle  phases  that 
are  characterized  by  an  ongoing  development 
requirement  as  well  as  a  much  larger 
cumulative  sustainment  effort,  e.g.,  propulsion. 

Product  Group  Manager  (PGM)  -  The 

individual  managing  an  AFMC  Product  Group 
who  is  ultimately  responsible  and  accountable 
for  decisions  arid  resources  in  overall  product 
group  management.  The  PGM  is  the  single 
person  who  is  charged  with  all  cost,  schedule 
and  performance  aspects  of  a  product  group 
and  related  sustainment  doiivlfies.  Typically, 
the  PGM's  product  is  in  direct  support  of  one  or 
more  military  systems. 

Production  and  Deployment  Phase  -  Known 
as  Phase  III  in  the  acquisition  process,  following 
a  Milestone  III  decision.  The  objectives  of  this 
phase  are  to  establish  a  stable,  efficient 
production  and  support  base,  achieve  an 
operational  capability  that  satisfies  the  mission 
need,  and  conduct  follow-on  operational  and 
production  verification  testing  to  confirm  and 
monitor  performance  and  quality  and  verify  the 
correction  of  deficiencies. 

Program  (Acquisition)  -  A  defined  effort 
furxfed  by  Research  Development  Test  & 
Evaluation  (RDT&E)  and/or  procurement 
appropriations  with  the  express  objective  of 
providing  a  new  or  improved  capability  in 
response  to  a  stated  mission  need  or  deficiency. 

Program  Alternatives  Assessment  (PAA)  - 

Ensures  that  the  business,  financial,  and 
political  risks  are  examined  for  each  concept 
being  considered  during  Concept  Exploration. 

Program  Baseline  -  A  formal  agreement 
between  the  Defense  Acquisition  Executive 
(DAE),  Service  Acquisition  Executive  (SAE), 
Program  Executive  Officer  (PEO)  and  the 
Program  Manager  (PM)  that  briefly  summarizes 
the  program  functional  specifications,  cost, 
schedule  and  other  factors  critical  to  program 
success.  The  Program  Baseline  is  integral  to 
Milestones  I,  II  and  III  approval  and  cannot  be 
changed  without  DAE  approval.  Within  the 
Program  Baseline  scope,  the  PM  is  given  full 
authority  to  manage  the  program.  Congress 


requires  a  development  baseline  (MS  II)  aixl 
production  baseline  (MS  III)  for  all  major 
defense  acquisition  programs.  For  Defense 
Enterprise  Programs,  a  baseline  is  submitted  to 
Congress. 

Program  Database  -  A  central  location  for  the 
collection  and  storage  of  information/data  to 
support  the  project  teams  and  subsequent 
System  Program  Office  (SPO)  in  making 
decisions  that  respond  to  external  and  internal 
requirements  (i.  e.,  information  needs  of  the 
Milestone  Decision  Authority  (MDA)). 

Program  Decision  Memorandum  (PDM)  -  Any 
issues  that  are  approved  by  the  Secretary  of 
Defense  are  recorded  in  the  PDMs  and  the  PDM 
is  used  to  update  the  Senrice's  databases  and 
Program  Objective  Memorandum  (POM) 
documentation. 

Program  Element  Monitor  (PEM)  -  Person  with 
HQ  USAF  office  of  primary  responsibility  who  is 
directly  responsible  for  a  given  program  and  all 
documentation  needed  to  hamnonize  the 
program  in  the  budget. 

Program  Executive  Officer  (PEO)  -  A  military 
or  civilian  official  who  has  primary  responsibility 
for  directing  several  acquisition  category  I 
programs  and  for  assigned  acquisition 
categories  II,  III,  and  IV  programs.  A  PEO  has 
no  other  command  or  staff  responsibilities 
within  the  Component,  and  only  reports  to  and 
receives  guidance  and  direction  from  the  DoD 
Component  Acquisition  Executive  (CAE). 

Program  Life  Cycle  Cost  Estimate  (PLCCE)  - 
A  military  or  civilian  official  who  has  primary 
responsibility  for  directing  several  acquisition 
categroy  I  programs  and  for  assigned 
acquisition  category  II,  III,  and  IV  programs.  A 
PEO  has  no  other  command  or  staff 
responsibilities  within  the  Component,  and  only 
reports  to  and  receives  guidance  and  direction 
from  the  DoD  Component  Acquisition  Executive 
(CAE). 

Program  Management  -  (1)  The  process 
whereby  a  single  leader  and  team  are 
responsible  for  planning,  organizing, 
coordinating,  directing  and  controlling  the 
combined  efforts  of  participating/assigned 
civilian  and  military  personnel  and  organizations 
in  accomplishement  of  program  objectives.  (2) 
The  concept  of  program  management  is  defin^ 
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as  a  special  management  approach  used  to 
provide  centralized  authority  and  responsibility 
(on  a  team  or  task  force  basis)  for  priority 
accompHshments  of  a  specified  project  or  task. 
The  ta^  critical  to  organization  success 
involves  the  timely  integration  of  divergent 
specialists  and  activities  into  coherent, 
coordinated  management.  (3)  Program 
management  provides  a  single  point  of  contact 
as  the  major  force  for  directing  the  system 
through  evolution,  development,  production  and 
deployment. 

Program  Management  Directive  (PMO)  - 

Directs  programmatic  responsibilities  to  major 
command,  field,  and  test  organizations  for 
systems  development,  modification,  or 
acquisition  in  broad  terms.  It  originates  within 
the  Headquarters  (Secretariat  and  Air  Staff)  and 
is  coordinated  with  all  outside  implementing, 
supporting,  participating,  operating,  and  test 
agencies.  The  intent  of  the  PMD  is  to  integrate 
all  activities  which  affect  the  life  cycle  of  a 
program.  All  Air  Force  programs  are  required  to 
have  a  complete  and  current  PMO. 

Program  Management  Plan  (PMP)  -  The 

document  developed  and  issued  by  the  program 
manager  which  shows  the  integrated  time- 
phased  actions  and  resources  required  to 
complete  the  task.  Certain  nonmajor  programs 
may  use  a  PMP  to  replace  all  the  functional 
plans,  but  the  PMP  is  generally  not  used  on 
major  programs. 

Program/Project  Manager  (PM)  -  Official 
responsible  for  managing  a  specific  acquisition 
program  who  reports  to  and  receives  direction 
from  either  a  Pr^ram  Executive  Officer  (PEO) 
or  Senrice  Acquisition  Executive  (SAE).  The 
PM,  while  perhaps  being  unable  to  control  the 
environment,  nevertheless  has  management 
authority  over  business  and  technical  aspects  of 
a  specifically  defined  program.  The  PM  has 
only  one  responsibility  and  that  is  managing  the 
program.  Accountability  is  clearer,  and  results 
should  be  more  easily  quantifiable  and 
measurable.  The  effective  PM  has  the 
advantage  of  a  large  perspective  of  the  program 
and  the  interrelationships  among  its  elements. 
The  PM  is  a  leader  and  manager,  not  primarily  a 
"doer;’  understands  the  requirements, 
environment,  organizations,  activities, 
constraints,  nxjtivations  impacting  the  program; 
knows  and  is  capable  of  working  within  the 
established  framework,  managerial  systems  and 


processes  that  provide  funding  arfo  other 
decisions  for  the  program  to  proceed; 
comprehends  and  uses  basic  skWs  of 
management-planning,  organizing,  directing  and 
controlling,  so  p^le  and  systems  harmonize  to 
produce  the  desired  results;  coordinates  the 
work  of  defense  industry  contractors, 
consultants,  in-house  engineers  and  logisticians, 
contracting  officers,  and  others,  whether 
assigned  directly  to  the  program  office  or 
supporting  it  thr^h  a  matrixed  assi^ment 
format.  Also  called  a  Project  Manager  (PM), 
Program  Director  (PD),  or  System  Program 
(SPM). 

Programmatic  -  Pertains  to  the  acquisition 
program  itself  (i.  e..  Procurement  numbers, 
manpower,  performance  characteristics, 
mission,  availability,  etc.). 

Program  Objective  Memorandum  (POM)  -  A 

biennial  memorandum  submitted  to  the 
Secretary  of  Defense  (SECDEF)  from  each 
Military  Department  and  Defense  agency.  It 
proposes  total  program  requirements  for  the 
next  6  years.  It  includes  rationale  for  planned 
changes  from  the  approved  Future  Years 
Defense  Plan  (FYDP)  baseline  within  the  fiscal 
guidance  issued  by  the  SECDEF. 

Program  Objective  Memeorandum  (POM) 
Wedge  -  Ensures  that  projected  funding  for  a 
potential  acquisition  program  over  the  next  8 
years  is  planned  into  the  Planning, 

Programming  and  Budgeting  System  (PPBS)  as 
soon  as  possible. 

Program  Protection  Plan  (PPP)  -  The  PPP  is 
the  overall  operational  security  plan  for  the 
project/program.  Some  of  the  items  to  be 
considered  in  the  PPP  include;  Essential 
Elements  of  Friendly  Infonnation  (EEFI), 
security  capabilities  and  procedures  at  all  the 
facilities  involved  with  the  project/program, 
security  classification  guide,  required  security 
resources,  etc. 

Program  Research  and  Development 
Announcements  (PRDA)  -  A  publication  in  the 
Commerce  Business  Daily  (CBD)  of  a  rer^iring 
activity's  interest  in  new  and  creative  research 
or  development  solutions  to  scientific  or 
engineering  problems,  with  the  intent  to  solicit 
proposals.  This  announcement  may  be  an 
appropriate  contracting  method  for  exploratory 
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research  that  has  general  application  and  is  not 
system  specific. 

Program  Technical  Library  -  A  central  location 
where  key  releasable  documents  are  made 
available  for  potential  offerors  review.  The 
project  manager  authorizes  use  of  a  program 
technical  Kbrary  and  determines  which 
information  and  at  what  stage  of  development 
win  be  provided  in  the  library.  Once 
established,  the  location  must  be  publicized  in 
the  Commerce  Business  Daily  (CBD).  Every 
effort  should  be  made  to  ensure  all  potential 
offerors  have  equal  and  open  access  to  library 
information. 

Project -(1)  Synonymous  with  program  in 
general  usage.  (2)  Specifically,  a  planned 
undertaking  involving  definition,  development, 
production,  and  logistics  support  of  a  major 
weapon  system  or  systems.  A  project  may  be 
the  whole  or  part  of  a  program. 

Project  Manager  -  The  individual  on  whose 
shoulders  rests  the  proper  execution  of  the 
project  plans.  The  project  manager  has  to  be 
very  versatile  and  effective  in  handling  all  kinds 
of  project  situations,  whether  positive  or 
negative.  See  Program  Manager. 

Project  Summary  Work  Breakdown  Structure 
(WBS)  -  A  summary  WBS  tailored  to  a  specific 
defense  material  Kern  by  selecting  applicable 
elements  from  one  or  more  summary  WBS's  or 
by  adding  equivalent  elements  unique  to  the 
project. 

Project  Team  -  An  integrated  core  team  of 
experienced  acquisition  experts  responsible  for 
initiating  acquisition  project  activities,  including 
preliminary  Phase  0  planning,  and  for 
corxfucting  initial  conceptual  studies. 

Request  For  Information  (RFI)  -  This 
announcement  provides  a  broad  statement  of 
need,  briefly  describes  the  government's 
intentions  regarding  program/acquisition 
approach,  and  identifies  key  events.  It  also 
requests  industry  comments  on  how  the 
government  can  satisfy  its  needs;  alternative 
approaches;  technology  availability  and  risk;  the 
identification  of  cost  drivers;  and  suggestions  on 
ways  to  enhance  or  sustain  competition. 


Requatt  for  Proposal  (RFP)  -  A  solicitation 
used  in  a  negotiated  acquisition  to  communicate 
government  requirements  to  prospective 
contractors  and  to  solicit  proposal. 

Requirement- (1)  The  need  or  demand  for 
personnel,  equipment,  facilities,  other 
resources,  or  services,  by  specified 
quantitatives  for  specific  periods  of  time  or  at  a 
specified  time.  (2)  For  use  in  budgeting,  item 
requirements  should  be  screened  as  to 
individual  priority  and  approved  in  the  light  of 
total  available  budget  resources. 

Requirements  Analysis  -  Serves  as  the 
principal  link  between  the  two  operator  lead 
activities  (mission  need  statement  preparation 
and  operational  requirements  definition)  and  the 
devel^r’s  task  of  identifying  viable  conceptual 
design  solutions  and  assessing  their 
performance. 

Requirements  Correlation  Matrix  (RCM)  -  A 

three-part  matrix  spreadsheet  used  to  provide  a 
system  audit  trail  of  the  capabilKies  and 
characteristics  identified  in  the  Operational 
Requirements  Document  (ORD).  User  system 
requirements  are  identified  in  terms  of 
thresholds  and  objectives;  and  the  user  is  also 
responsible  for  identifying  the  key  parameters. 

Resource  -  Any  person,  tool,  equipment,  or 
material  used  to  complete  an  activity  or  task. 

Resource  Allocation  Process  -  Includes  the 
Planning  Programming  Budgeting  System 
(PPBS),  congressional  budget  enactment 
process  apportionment  of  appropriated  funds 
and  budget  execution. 

Resource  Allocation  Team  (RAT)  -  The  RATs 
are  the  focal  points  for  resource  issues  for  the 
functional  areas  of  Nuclear  Deterrence,  Power 
Projection,  Global  Mobility,  Space  and 
Command  Control  Communications,  Materiel 
Support,  Personnel  Support,  Classified 
Programs,  and  National  Foreign  Intelligence 
Programs. 

Requirements  Correlation  Matrix  •  A  three- 
part  matrix  spreadsheet  used  to  provide  a 
system  audit  trail  of  the  capabilities  and 
characteristics  identified  in  the  Operational 
Requirements  Document  (ORD). 
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Requiranwfits  Summit  -  See  Summit. 

Risk  -  A  subjective  assessment  made  regarding 
the  likelihood  or  probability  of  not  achieving  a 
specific  objective  by  the  time  established  with 
the  resources  provided  or  requested.  It  also 
refers  to  overall  program  risk. 

Risk  Analysis  •  An  examination  of  risk  areas  or 
events  to  determine  options  and  the  probable 
consequences  for  each  event  in  the  analysis. 

Risk  Assessment  -  The  process  of  subjectively 
determining  the  probability  that  a  specific 
interplay  of  performance,  schedule,  and  cost  as 
an  objective,  will  or  will  not  be  attained  along 
the  planned  course  of  action. 

Risk  Management  -  All  actions  taken  to 
identify,  assess,  and  eliminate  or  reduce  risk  to 
an  acc^able  level  in  selected  areas  (e.g.,  cost, 
schedule,  technical,  producibility,  etc.);  and  the 
total  program. 

Risk  Management  Plan  (RMP)  -  Defines  how 
risk  analysis  will  be  performed.  The  purpose  of 
the  risk  analysis  is  to  anticipate  the  significant 
things  that  could  go  wrong,  develop  contingency 
plans  in  case  they  do  go  wrong,  and  estimate 
the  cost  and  schedule  impact  for  each  area  of 
risk. 

Service  Acquisition  Executive  (SAE)  -  Within 
each  Military  Department,  designated  by  the 
Component  Head,  the  SAE  is  responsible  for 
administering  acquisition  programs  in 
accordance  with  established  DoD  policies  and 
guidelines.  SAE  also  applies  to  the  senior 
acquisition  executive  within  any  DoD 
Component  having  cognizance  over  an 
acquisition  program.  The  SAE  is  also  the  senior 
procurement  executive  for  each  Military 
Department.  In  the  Air  Force,  the  Assistant 
Secretary  for  Acquisition,  SAF/AQ,  is  also  the 
Air  Force  SAE. 

Solicitation  -  In  contracting,  the  term  means  to 
go  out  to  prospective  bidders  and  request  their 
response  to  a  proposal. 

Source  Selection  -  The  evaluation  process 
where  a  team  of  acquisition  professionals 
review  the  proposals  submitted  in  response  to 
Request  for  Proposals  (RFPs).  The  strengths, 
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weaknesses,  and  risks  associated  wkh  each 
proposal  are  documented  in  Source  Selec^n. 

Source  Selection  Advisory  Council  (SSAC)  - 
The  chairperson  of  the  SSAC  is  the  individual 
responsible  for  the  release  of  the  notice  on 
major  acquisitions,  and  for  less-than-major 
acquisitions,  the  contracting  officer  is 
responsible  for  ensuring  the  notice  of  the  source 
selection  action  is  accomplished.  The  notice 
kfertifies  the  system,  subsystem,  or  project 
involved,  the  anticipated  period  of  the  source 
selection,  and  includes  a  statement  stating  that 
contacts  by  participating  offerors  are  not  aHowed 
regarding  the  proj^. 

Source  Selection  Authority  (SSA)  •  The  SSA 
determines  which  contractor  is  best  qualified  to 
fulfill  the  government's  requirements  at  an 
affordable  cost  based  upon  the  results  of  the 
Source  Selection  evaluation. 

Source  Selection  Evaluation  Board  (SSEB)  - 

A  group  of  military  and/or  government  civilian 
personnel,  representing  functional  and  technical 
disciplines.  It  is  charged  with  evaluating 
proposals  and  developing  summary  facts  and 
findings  during  source  selection. 

Source  Selection  Plan  (SSP)  -  A  key 
document  that  specifies  how  the  source 
selection  activities  will  be  initiated  and 
conducted.  It  serves  as  a  guide  for  conducting 
the  evaluation  and  analysis  of  proposals,  and 
the  selection  of  sources  for  the  acquisition.  It 
can  best  be  described  as  the  blueprint  for 
conducting  the  source  selection. 

Specification  -  A  document  intended  primarily 
for  use  in  procurement,  which  clearly  and 
accurately  describes  the  essential  technical 
requirements  for  items,  materials  or  services 
including  the  procedures  by  which  it  will  be 
determined  that  the  requirements  have  been 
met.  Specifications  may  be  prepared  to  cover  a 
group  of  products,  services,  or  materials,  or  a 
single  product,  service  or  material,  aixl  are 
general  or  detail  specifications. 

SPO  Cadre  -  Multi-discipline  team  formed  after 
Milestone  0  approval  (with  the  Project  team  as 
the  core)  to  c^uct  the  Concept  Exploration 
and  Program  Definition  phase.  This  group 
develops  the  initial  plans  and  schedules  to 
execute  the  future  program. 
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Stlmut  of  Work  (SOW)  -  That  portion  of  a 
contract  which  establishes  and  defines  all 
nonspecification  requiremertts  for  contractors 
efforts  either  directly  or  with  the  use  of  specific 
cited  documents. 

Steering  Group  -  A  one-time,  periodic,  or  on¬ 
going  activity  which  pulls  together  appropriate 
management  and/or  technical  expertise  to 
direct,  assist,  guide,  or  execute  an  assigned 
task.  Steering  groups  are  typically  formed  to 
provide  management  oversight,  guidance, 
advice,  or  approval  authority  for  specified 
activities. 

Strategy-To-Task  Process  (Analysis)  -  The 

’strategy-to-task’  process  links  the  need  for 
certain  military  capabilities  to  the  military 
strategy  provided  by  the  Chairman  of  the  Joint 
Chiefs  of  Staff  (CJCS). 

Strategic  Roundtable  I  (See  lASP)  -  Ensures 
senior  experienced  management  involvement 
early  in  formulating  the  initial  project/program 
acquisition  strategy.  This  roundtable  helps  the 
project  manager  formulate  a  sound,  disciplined 
initial  acquisition  strategy  by  giving  a 
project/program  the  benefit  of  the  members' 
expert  acquisition  knowledge  and  advice. 

Strawman  -  A  working  draft  copy  circulated  for 
comments  or  suggested  changes. 

Study  Advisory  Group  (SAG)  -  A  senior 
advisory  group  comprised  of  experienced 
personnel  from  different  commands  to  oversee 
the  mission  planning  and  requirements 
activities. 

Summit  (Requirements  and  Acquisition 
Program  Review)  -  A  senior  level  review, 
chaired  by  the  Chief  of  Staff,  U.  S.  Air  Force,  for 
all  ongoing  major  defense  acquisition  programs. 
Summits  will  normally  be  convened  b^een 
Milestone  0-1,  Milestones  l-ll,  and  Milestones  II- 
III  to  review  and  affirm  user-stated  needs  and 
requirements  and  the  adequacy  of  program 
development  efforts  to  satisfy  those  needs  in  a 
timely,  cost-effective  manner. 

Supporting  Command  -  The  command 
(Usually  Air  Force  Materiel  Command) 
responsible  for  providirtg  logistics  support  for  a 
system  and  assuming  program  management 
responsibility  from  the  Implementing  Command. 


System  -  (1)  The  organization  hardware, 
software,  material,  facilities,  personnel,  data, 
and  services  needed  to  perform  a  designated 
function  with  spewed  results,  such  as  the 
gathering  of  specified  data,  its  processing,  and 
delivery  to  users.  (2)  A  combination  of  two  or 
more  interrelated  equipment  sets  arrang^  in  a 
ftjnctbnal  package  to  perform  an  operational 
fcirxftion  or  to  satisfy  a  requirement. 

System  Artalysis  -  A  man^ment  planning 
technique  which  applies  scientific  planning 
methods  of  many  disciplines  to  major  problems 
or  decisions.  The  list  of  disciplines  includes,  but 
is  rtot  limited  to,  traditional  military  planning, 
economics,  political  science  and  social 
sciences,  applied  mathematics,  and  the  physical 
sciences. 

System  Program  Director  (SPD)  -  The 
individual  directing  an  AFMC  System  Program 
Office  (SPO)  who  is  ultimately  responsible  and 
accountable  for  decisions  and  resources  in 
overall  program  execution  of  a  military  system. 
The  SPD  is  the  single  person,  identifi^  in  a 
Program  Management  Directive  (PMD),  who  is 
charged  with  all  cost,  schedule,  performance, 
and  sustainment  aspects  of  a  directed 
acquisition  program.  The  SPD's  primary 
customer  is  the  using  MAJCOM. 

System  Program  Office  (SPO)  -  The  office  of 
the  program  manager  and  the  single  point  of 
contact  with  industry,  government  agencies  and 
other  activities  participating  in  the  system 
acquisition  process. 

System  Threat  Assessment  (ST A)  -  The  basic 
authoritative  threat  assessment,  taibred  for  and 
focused  on.  a  particular  acquisitbn  category  II 
through  IV  program.  It  describes  the  threat  to 
be  countered  and  the  projected  threat 
environment.  The  STA  may  be  a  stand-alone 
document  or  the  threat  assessment  contained  in 
the  Operational  Requirements  Document 
(ORD).  The  threat  informatbn  is  based  on 
Defense  Intelligence  Agency  validated 
documents. 

System  Threat  Assessment  Report  (STAR)  - 

The  basb  authoritative  threat  assessment, 
tailored  for  and  focused  on,  a  particular  major 
defense  acquisition  program.  It  describes  the 
threat  to  be  countered  and  the  projected  threat 
environment.  The  threat  informatbn  is  based 
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on  Defers  Intelligence  Agency  validated 
documente. 

Systeme  AequiMion  Procees  -  The  sequence 
of  acquisition  activities  starting  from  the 
agerx:y's  recondUalion  of  te  mission  need,  witti 
its  cap^Mies,  priorities  and  resources,  and 
exteriding  through  the  introduction  of  a  system 
into  operational  use  of  the  otherwise  successful 
achievement  of  pro^am  activities. 

Systems  Engineering  - 1  he  application  of 
scientific  and  engineering  efforts  to  (1 ) 
transform  an  operational  need  into  a  description 
of  system  performance  parameters  and  a 
system  configuration  through  the  use  of  an 
iterative  process  of  oefinition,  synthesis, 
analysis,  design,  test,  and  evaluation:  (2) 
integrate  related  technical  parameters  and 
ensure  compatibility  of  all  physical,  functional, 
and  program  interfaces  in  a  nrtanner  that 
optimizes  the  total  system  definition  and  design; 
(3)  irrtegrate  reliability,  maintainability,  safety, 
survivability,  human,  and  other  such  factors  into 
the  total  engineering  effort  to  meet  cost, 
schedule,  and  technical  performance  objectives. 

System  Maturity  Matrix  (SMM)  -  An  acquisition 
management  tool  used  for  evaluating  weapon 
system  capability  during  the  acquisition  life 
cycle.  The  SMM  includes  significant 
parameters  necessary  to  measure  progress 
toward  meeting  the  Operating  Command 
requirements.  The  Iniplementing  (lead)  and 
Operating  Commands  develop  and  update  the 
SMM  and  coordinate  it  with  the  Supporting 
Command,  the  operational  test  agency,  and  HQ 
USAF/XOR.  It  contains  a  time-phased 
comparison  of  the  user's  system  requirements 
and  contractual  specifications  which  lead  to 
maturity.  It  can  tie  event  driven. 

Systems  Engineering  Management  Plan 
(SEMP)  -  A  concise  top  level  technical 
management  plan  for  the  integration  of  all 
systems  engineering  activities.  It  includes  plans 
for  verification,  risk  alleviation,  analyses  and 
simulation  of  the  system  requirements. 

Systems  Engineering  Master  Schedule 
(SEMS)  -  The  SEMS  is  a  top-level  tool  used  to 
measure  progress  toward  completion  of  the 
systems  engineering  activities  outlined  in  the 
systems  engineering  management  plan 
(SEMP).  The  SEMS  includes  a  set  of  exit 
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criteria  for  each  of  the  systems  engmeering 
tasks  listed  in  the  SEMP  which  must  be 
successfully  met  prior  to  proceeding  to  the  noct 
task.  It  is  not  a  time-line  but  an  event-based 
flow  of  activities.  Progress  toward  completion  is 
based  on  a  percentage  of  completed  sy^ems 
er^gmeering  tasks,  not  on  where  your 
project/program  is  based  on  the  calendar. 

Tactical  Roundtable  H  (See  lASP)  -  The 
tactical  roundtable  builds  strategy  alternatives 
with  timing  constraints  and  completes 
development  of  the  Integrated  Program 
Summaries  (IPS)/Acquisition  Strategy  Report 
(ASR).  This  roundtable  summarizes  where  the 
project  is,  versus  where  it  should  be,  describes 
where  the  program  is  going,  and  how  it  will  get 
there,  and  identifies  proje^  risk  area  and  plans 
for  managing  risk.  It  provides  the  basis  for 
establishing  explicit  project  cost,  schedule,  and 
performance  objectives.  Roundtable  II  will  give 
the  project  a  systematic  approach  to  completing 
a  successful  Acxyjisition  Strategy  Panel  (ASP) 
with  limited  manpower  of  today's  limited 
resource  environment. 

Tailoring  -  Usually  referring  to  acquisition 
strategy  (AS),  tailoring  allows  the  ^  to  be 
written  to  suit  an  individual  program  need.  No 
strict  format  must  be  followed.  Basics  must  be 
addressed,  but  the  program  manager  has 
authority  to  design/plan  for  specific 
requirements  to  meet  optional  balance  between 
need  and  cost. 

Tailoring  (Joint  Program)  -  The  process  of 
evaluating  potential  requirements  of  the 
participating  services  to  determine  their 
pertinence  and  cost  effectiveness  for  a  specific 
system  or  equipment  joint  acquisition,  and 
modifying  these  requirements  to  ensure  that 
each  contributes  to  an  optimal  balance  between 
the  needs  of  the  participating  Services  and  cost. 

Task  Order  Contract  -  Laboratory  and 
development  planning  support  may  be  provided 
by  use  of  contracts  utilizing  task  ordering 
arrangements.  Task  ordering  arrangements  are 
appropriate  for  those  instances  in  which  a 
defined  need  exists  for  contractual  support  of 
the  scientific  and  technical  mission  for  which  the 
precise  nature,  quantity  or  schedule  of  the 
requirement  effort  cannot  be  precisely 
determined  in  advance.  It  defines  the 
description,  specifications,  and  statement  of 
work  in  general  terms. 
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Taak-To>NMd  PracMS  -  The  evaluation  o(  Air 
Force  ability  to  accomplish  identified  tasks  and 
missions  using  current  and  programmed  forces. 

Technical  Data  Package  (TOP)  -  Those 
documents,  drawings,  reports,  manuals, 
reveions,  technical  orders,  or  other  submissions 
as  set  forth  as  a  CDRL  line  item  to  be  delivered 
as  required  by  the  corttract.  Also.  TOP  may  be 
obtained  by  government  to  provide  competition 
in  production. 

Technical  Evalualion  -  The  study, 
investigations  or  the  Test  &  Evaluation  (T&E)  by 
a  developing  agency  to  determirte  the  technical 
suitability  of  materiel,  equipment,  or  a  system, 
for  use  in  the  military  services. 

Technical  Infonnation  -  Information  including 
scientific,  which  relates  to  research, 
development,  engineering,  test,  evaluation, 
production,  operation,  use  and  maintenance  of 
munitions  and  other  military  supplies  and 
equipment. 

Technical  Performance  Measurement  (TPM)  - 

Describes  all  the  activities  undertaken  by  the 
government  program  management  office  to 
obtain  design  status  beyond  that  treating 
schedule  and  cost.  TPM  is  defined  as  the 
product  design  assessment  which  estimates, 
through  tests,  the  values  of  essential 
performance  parameters  of  the  current  design 
of  work  breakdown  structure  product  essentials. 

It  forecasts  the  values  to  be  achieved 
throughout  ’he  planned  technical  program  effort, 
measures  differences  between  achieved  values 
and  those  allocated  to  the  product  element  by 
the  system  engineering  process,  and  determines 
the  impact  of  these  differences  on  system 
effectiveness. 

Technical  Planning  Integrated  Product 
Teams  (TPIPTS)  -  TPIPTS  are  networks  of 
experts  from  the  acquisition  and  operational 
commands  who  plan  and  facilitate  the  transition 
of  technical  solutions  to  users'  long  term 
operational  needs.  They  facilitate  the  initial 
planning  and  development  leading  to  technically 
si^rior  solutions  to  both  the  long  and  short 
term  operational  needs  of  the  users.  A  typical 
TPIPT  consists  of  a  network  of  development 
planners.  Operational  Command  users, 
technology  planners  from  Air  Force  laboratories, 
logistics  center  planners,  system  engineers,  and 


representatives  from  test  organizations, 
program  offices,  and  intelligent  agencies. 
TPIPTS  are  organized  by  mission  or  functional 
area  to  gather,  analyze,  coordmate,  and 
disseminate  information  in  each  Air  Force 
mission  area.  Each  product,  logistics,  and  test 
center  may  have  several  TPIPTS  orgarrized 
according  to  applic^>le  mission  areas  and  led 
by  development  planners  in  XR. 

Technology  Modernization  -  The  coupivig  of 
modernization  with  the  wnplementation  of 
advanced  manufacturing  technology  by 
providing  incentives  for  contractor  (and 
subcontractor)  capitalization. 

Technology  Needs  Assessment  ■  Assessment 
of  the  operational  requirements  and  conceptual 
designs  resulting  from  Concept  Exploration 
Studies  to  determine  the  types  of  technology 
which  need  to  be  applied  to  the  conceptual 
designs  so  that  operatbnal  requirements  can 
be  accomplished. 

Test  -  Any  program  or  procedure  which  is 
designed  to  obtain,  verify,  or  provide  data  for 
the  evaluation  of  resear^  and  developnrent 
objectives;  or  performance  experiments); 
progress  in  accomplishing  development 
objectives;  or  performance  and  operational 
capability  of  systems,  subsystems,  components, 
arb  equipment  items. 

Test  and  Evaluation  (T&E)  -  Process  by  which 
a  system  or  components  are  compared  against 
requirements  and  specifications  through  testing. 
The  results  are  evaluated  to  assess  progress  of 
design,  performance,  supportabiiity,  etc.  There 
are  three  tyj^es  of  T&E  -  Development  (DT&E). 
Operational  (OT&E),  and  Production 
Acceptance  (PAT&E)  -  -  occurring  during  the 
acquisition  cycle.  DT&E  is  conducted  to  assist 
the  engineering  design  and  development 
process  and  to  verify  attainment  of  technical 
performance  specificatbns  and  objectives. 
OT&E  is  conducted  to  estimate  a  systems 
operational  effectiveness  and  suitability,  bentify 
needed  modificatbns,  and  provbe  informatbn 
on  tactics,  doctrine,  organizatbn,  and  personnel 
requirements.  PAT&E  is  conducted  on 
productbn  items  to  demonstrate  those  items 
meet  the  requirements  arb  specificatbns  of  the 
procuring  contracts  or  agreements.  OT&E  is 
further  subdivided  into  two  phases  -  Initial 
Operatbnal  (lOT&E)  and  Follow-on  Operatbnal 
(FOT&E).  lOT&E  must  be  conducted  on  a 
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system  as  cioee  to  a  production  configuration  as 
possible,  in  an  operationally  realistic 
environment,  by  typical  user  personnel.  FOT&E 
is  cofKiucted  on  the  deployed  system  to 
determine  U  operational  effectiveness  and 
suitability  is,  in  fact,  being  attained. 

Teat  Integration  Working/Test  Planning 
Working  Group  •  A  working  group  designed  to 
facilitate  the  integration  of  test  requirements 
through  close  coordination  between  the  material 
developer;  combat  developer  and  operational 
tester  in  order  to  minimize  development  time 
and  cost  and  preclude  duplication  between 
developmental  and  operational  testing. 

Test  Mlanagement  Council  (TMC)  -  Reviews 
design  test  and  evahjation  program  progress  in 
relation  to  overall  program  goals  and  objectives. 

Test  Plan  Working  Group  (TPWG)  -  The 
TPWG  acts  as  a  forum  for  test  and  evaluation 
(T&E)  related  subje^.  The  TPWG  helps  draft 
the  test  and  evaluation  master  plan. 

Threat  -  The  sum  of  the  potential  strengths, 
capabilities  and  strategic  objectives  of  any 
adversary  which  can  limit  or  negate  U.S.mission 
accomplishment  or  reduce  force,  system  or 
equipment  effectiveness. 

Threat  Environment  Description  (TEDs)  - 
TEDs  are  HQ  USAF/IN-approved,  contractor- 
releasable  references  for  threat  information 
associated  with  US  Air  Force  mission  areas  and 
other  specialized  tasks.  They  have  applicability 
throughout  the  acquisition  process.  TEDs  serve 
as  threat  documents  for  pre-Milestone  0 
analyses,  arxl  may  be  used  in  support  of 
programs  not  subject  to  the  Air  Force  Systems 
Acquisition  Review  Council  (AFSARC)  and 
Defense  Acquisition  Board  (DAB)  milestone 
review  process.  They  support  System  Threat 
Assessment  Reports  (STARs)  as 
complementary  documents  by  addressing  an 
entire  Air  Force  mission  area,  thus  providing  a 
breadth  and  scope  not  found  in  STARs.  They 
may  also  serve  as  an  initial  basis  from  which  to 
develop  a  STAR. 

Threat  Environment  Projection  (TEP)  -  The 

TEP  is  an  overview  of  the  operational,  physical, 
and  technological  environment  in  which  the 
system  will  have  to  function  during  its  lifetime. 
Developments  and  trends  which  can  be 


expected  to  affect  mission  capability  should  be 
pr^ected  out  k>  the  end  of  the  system  life  (^e. 
Areas  covered  should  include  ertemy  doctrine, 
^ategy,  and  tactics  affecting  system  mission 
and  operations.  Threat  content  and  emphasis 
will  vary  based  on  the  program  or  area  ol 
vterest  being  address^. 

Threat  Plannii^  Document  -  A  threat 
document  that  is  identical  in  formal  and  content 
to  a  System  Threat  Assessment  Report  (STAR) 
and  Threat  Assessment  Report  (T AR)  arid  is 
prepared  by  the  Director  of  Intelligent  (Dl)  for 
programs  that  require  a  system-specific  threat 
assessment  but  are  below  Air  Fort  Systems 
Acquisition  Review  OMirKH  (AFSARC)  level. 

Threat  Steering  Group  (TSG)  -  A  joint-service 
and  DoD  ad  hoc  intelligence  group  that  plans 
threat  support  of  joint  service  or  complex 
system  acquisitions. 

Threat  Working  Group  (TWG)  -  Effective 
means  of  providing  threat  suppt  to  a  program, 
ft  gives  advice,  guidance,  and 
recommendatiorrs  to  the  project  manager  on 
effective  responses  to  the  threat  environment. 

Thresholds  -  (1 )  Monetary,  time,  or  resource 
limitaiions  placed  on  a  program,  to  be  used  as 
guides  as  the  program  progresses  and  the 
breaching  of  which  is  cause  for  careful  review  of 
at  least  some  aspects  of  the  program.  (2)  The 
minimum  level  a  system  must  meet  (e.g., 
performance  threshold  of  30k  ft  for  a  missile). 

Timeline  -  A  schedule  line  showing  key  dates 
and  planed  events. 

Under  Secretary  of  Defense  (Acquisition) 

(USD(A))  -  The  USD(A)  has  policy  and 
proce^ral  authority  for  the  defense  acquisition 
system  and  is  the  principal  acquisition  official  of 
the  Department  and  is  the  acquisition  advisor  to 
the  Secretary  of  Defense  (SECDEF).  In  this 
capacity  the  USD(A)  serves  as  the  Defense 
Ac^isition  Executive  (DAE),  the  Defense 
Procurement  Executive  and  the  National 
Armaments  Director,  the  last  regarding  matters 
of  the  North  Atlantic  Treaty  Organization 
(NATO).  For  acquisition  matters,  the  USD(A) 
takes  precedence  over  the  Secretaries  of  the 
Services  after  the  SECDEF  and  Deputy 
SECDEF.  The  USD(A)  authority  ranges  from 
directing  the  Services  and  Defense  Agencies  on 
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acquisition  matters,  to  establishii^  the  Defense 
Supplement  to  the  Federal  Acquisition 
Regulat^  (FAR)  and  chairing  ttie  Defense 
Acquisition  Board  (DAB)  for  major  defense 
acquisition  program  reviews. 

Using  Command  -  Usually  the  same  as  the 
Operating  Command.  Typically,  the  ultimate 
operaktrs  of  a  system.  There  are  some 
exceptions  (i.  e..  Headquarters,  Air  Combat 
Command)  which  can  be  the  using  command 
for  a  recormaissance  satellite  for  which  Air 
Force  Space  Command  is  operating  command. 

User  -  command,  unit  or  element  which  will  be 
the  recipient  of  the  production  item  for  use  in 
accomplishing  a  designated  mission. 

Validation  Authority  -  Validation  represents 
agreement  with  the  need  expressed  in  a  Mission 
Need  Statement  (MNS).  Validation  of  a  MNS  is 
determined  by  both  the  Acquisition  Category 
level  and  the  type  of  MNS  (i.e.,  single 
command,  multi-command,  joint,  etc.). 

WesfMn  System  •  Items  that  can  be  used 
directly  by  the  armed  forces  to  carry  out  combat 
missions  and  that  cost  more  than  $100,000  for 
which  the  eventual  total  procurement  cost  is 
nwe  than  $10,000,000.  A  weapon  system  is 
used  by  the  armed  forces  to  'war  fight."  It 
includ^  all  equipment  and  systems  used  by  a 
combatant  command;  i.e.,  trucks,  trailers, 
radios,  etc.,  as  well  as  ordnance,  guns  arid  the 
like  to  perform  a  specified  furx^ion  or  meet  a 
mission  need. 

Work  Breakdown  Structure  OVBS)  -  A 

product-oriented  family  tree  division  of 
hardware,  software,  services,  and  other  work 
tasks  which  organizes,  defines,  arxf  graphically 
displays  the  product  to  be  produced,  as  well  as 
the  work  to  be  accomplished  to  achieve  the 
specified  product. 

Working  Group  -  A  one-time,  periodic,  or  on¬ 
going  activity  which  pulls  together  appropriate 
managemern  aixf/or  technical  expertise  to 
direct,  assist,  guide,  or  execute  an  assigned 
task.  Working  groups  are  typically  formed  to 
manage  arKf  execute  a  specified  task. 


■*} 


» 


$ 


m 


•  • 


I 


• 1. 


A-24 


POP  GUIDE  BOOK 


Appendices 


APPENDIX  B 


PLANS  AND  DOCUMENTS 


MILESTONE  (MS)  0  DOCUMENTATION  REQUIREMENTS 

ACAT  LEVEL 

1  M'l  H  1  ill'l  1  if  li  1  1  III  1  "  1  1  IF 

1 

II 

III 

IV 

Mission  Need  Statement  (MNS) 

X 

X 

X 

X 

Defense  lntelligerK:e  Agency  Report  (DIA) 

0 

Intelligence  Report 

0 

0 

Acquisition  Decision  Memorarfoum  (ADM) 

0 

0 

0 

0 

TECHNICAL  PLANNING  DOCUMENTS 

Government-level  Systems  Engineering  Master  Plan  (SEMP)X 

X 

X 

X 

Outline 

Program  Protection  Plan  (PPP) 

X 

X 

X 

X 

Logistic  Support  Analysis  (LSA)  Strategy 

X 

X 

X 

X 

Strawman  Baseline  Concepts  Descriptions  (BCDs) 

X 

X 

X 

X 

Strawman  Systems  Requirements  Document  (SRD) 

X 

X 

X 

X 

Strawman  Systems  Engineering  Management  Schedule 

X 

X 

X 

X 

(SEMS) 

X;  PrepKired  By  Service  Operating  Command/Project  Team 

0: 

Prepared  by  OSD  Staff 

Table  1  Pre-kIS  0  Plans  and  Documents 

FORIMAL  DOCUMENTS: 

Mission  Need  Statement  (MNS)  -  A  document  prepared  to  identify  a  requirement  for  a  materiel  solution 
to  satisfy  a  mission  deficiency.  Prepared  by  Service/Unified  and  Specifi^  Commands  Joint  Staff/OSD 
Staff.  Approved  or  validated  by  Chairman,  Joint  Requirements  Oversight  Council  (JROC).  Prepared 
pre-MS  0  for  ACAT  I,  II,  III,  and  IV  programs  (C12). 

Defense  Intelligence  Agency  (DIA)  Intelligence  Report  -  Validates  the  basis  for  the  threat  in  the  MNS. 
Prepared  by  the  DIA  for  ACAT  ID  programs.  Approved  or  validated  by  the  Director,  Defense  Intelligence 
Ag^y  (DIA).  Not  required  for  ACAT  IC  programs  (AS). 

IntelligeiKe  Report  -  Validates  the  basis  for  the  threat  in  the  MNS.  Prepared  by  the  Component 
Intelligence  Command/Agency.  Approved  or  validated  by  the  Director,  Component  Intelligence 
Command/Agency.  Prepared  pre-MS  0  for  ACAT  II  and  III  programs. 

Acquisition  Decision  Memorandum  (ADM)  -  Provides  the  decisions  of  the  Milestone  Decision 
Authority  (MDA)  (including  approval  of  the  Acquisition  Strategy  Report  (ASR)  if  not  approved  prior  to  the 
MS)  and  the  exit  criteria  for  the  next  phase  of  the  project.  Prepared  by  DAB  Executive  Secretary  for 
ACAT  ID  programs.  Prepared  by  AFAE's  Staff  Executive  Secretary  for  ACAT  1C  programs.  Prepared 
by  MDA  Staff  for  ACAT  II,  III,  and  IV  programs  (A22). 
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TECHNICAL  PLANNING  REFERENCES: 

SEMP  Outlim  -  The  government  SEMP  provides  a  roadmap  of  required  technical  efforte  to  support  a 
'system*  throughout  its  life  cycle.  It  defines  what  must  be  done,  who  is  going  to  do  it.  what  mil^ones  it 
must  be  done  by,  input  data  owners,  output  data  users,  data  management  concept,  and  success  criteria 
(D20B). 

PPP  -  Identifies  essential  project  information,  technology  and  systems  to  be  protected.  It  creates  a 
management  plan  which  outlines  the  measures  that  ne^  to  be  taken  by  the  project  manager  to  protect 
the  system  throughout  the  acquisition  process  (020B). 

LSA  Strategy  -  Mission  area  mission  needs  analyses  are  performed  on  a  continuing  basis  to  include 
sunoQftabilitv  and  sustainability  considerations  within  mission  areas.  Program  requirements  ^ow  out  of 
these  analyses  (D20B). 

Strawman  BCOs  -  The  BCD  is  a  working  document,  providing  the  system  design  concepts  in  an  easily 
understood  format.  It  is  an  iterative  system  engineering  aid,  used  throughout  the  acquisition  phases  of  a 
system.  It  forms  the  common  baselme  for  understanding  the  proposed  candidate  concepts  identified, 
and  provides  a  common  understanding  from  which  the  SEMP  and  SEMS  can  be  generated  (D20B). 

Strawman  SRD  -  The  initial  source  of  requirements  is  the  MNS.  The  MNS  is  produced  through 
government  Mission  Needs  Analysis  (MNA)  studies  which  precede  the  Conce^  Exploration  and 
Definition  (CE&D)  phase.  These  requirements  are  often  summarized  for  the  contractors  in  aN  SRD. 
During  the  CE&D  phase,  requirements  from  the  SRD  are  further  analyzed  by  each  contractor  through  the 
systems  engineering  process  and  incorporated  into  the  system  specification  and  flowed  down  to  the 
lower  level  (D20B). 

Strawman  SEMS  -  A  top-level  process  control  and  progress  measurentent  tool  to  ensure  completion  of 
identified  accomplishments.  The  SEMS  accomplishments,  with  their  supporting  criteria,  shall  include 
those  necessary  to  provide  critical  technical  inputs  and  decision  data  into  engineering  (technical)  and 
project  decision  points,  demonstrations,  reviews  and  other  identified  events  (D20B). 
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MILESTONE  I  DOCUMENTATION  REQUIREMENTS 


FORMAL  DOCUMENTS  (format  in  DoD  5000.2-M)  I 
Operational  Requirements  Document  (ORO)  X 

System  Threat  Assessment  Report  (STAR)  X 

System  Threat  Assessment  (ST A) 

Integrated  Program  Summary  (IPS)  X 

Program  Life  Cycle  Cost  Estimate  X 

Acquisition  Program  Baseline  (APB)  X 

Test  &  Evaluation  Master  Plan  (TEMP)  X 

Component  Cost  Analysis  (CCA)  X 

Cost  &  Operational  Effectiveness  Analysis  (COEA)  X 

Defense  Intelligence  Agency  Report  (DIA)  O 

Intelligence  Report 

Joint  Requirements  Oversight  Council  (JROC)  Report  O 
Integrated  Program  Assessment  (IPA)  O 

Independent  Cost  Estimate  (ICE)  Re(^  O 

Acquisition  Decision  Memoraixfum  (ADM)  O 

FUNCTIONAL  PLANS 

Integrated  Weapon  System  Master  Plan  (IWSMP)  X 

Systems  Engineering  Management  Plan  (SEMP)  X 

Systems  Engineering  Master  Schedule  (SEMS)  X 

Risk  Management  Plan  (RMP)  X 

Program  Protection  Plan  (PPP)  X 

Integrated  Logistics  Support  Plan  (ILSP)  X 

Pollution  Prevention  Adion  Plan  (PPAP)  X 

Nuclear  Certification  Plan  (NCP)  (if  necessary)  X 

Cost  Analysis  Requirements  Description  (CARD)  X 

Program  Management  Plan  (PMP)  (May  be  used  on  X 
non-major  programs,  generally  not  used  on  major  programs) 
System  Security  Master  Plan  (SSMP)  X 

Computer  Resources  Life  Cycle  Management  Plan  X 

(CRLCMP) 

_ X:  Prepared  by  MilKary  Dept/Project  Team _ 


ACAT  LEVEL 
II  III 

X  X 


0:  Prepared  by  OSD  Staff 


Table  2  -  Milestone  I  Plans  and  Documents 
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FORMAL  DOCUMENTS: 


Operational  Requirements  Document  (ORD)  -  Identifies  minimum  acceptable  performance 
requirements  to  satisfy  the  operational  need;  also  includes  performance  objectives  that  would  provide 
operationally  meaningful  increases  in  capability.  Prepared  by  Operational  Command.  DoD  5000.2M, 
Part  3  contains  preparation  procedures  and  format  (C19  and  C26). 

System  Threat  Assessment  Report  (STAR)  -  The  STAR  is  the  authoritative  reference  for  threat  data 
supporting  a  major  acquisition  program.  STARs  are  required  for  ACAT  IC  and  ID  programs,  and  for 
major  modifications.  The  STAR  will  analyze  current,  projected  and  reactive  threats  the  system  will  face. 
Prepared  by  Component  Intelligence  Command/Agency.  DoD  5000.2M,  Part  5  contains  preparation 
procedures  and  format  (D50,  D56). 

System  Threat  Assessment  (ST A)  -  The  STA  is  the  authoritative  threat  reference  for  threat  data 
supporting  ACAT  ll-IV  programs.  ST As  for  ACAT  II  programs  are  stand-alone  documents  of  about  25 
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pages.  STAs  lor  ACAT  lll-IV  programs  are  contained  in  the  ORO.  Prepared  by  the  Air  Force 
Intelligence  Command/Agency.  For  procedures  and  format  requirements,  see  DoD  5000.2M,  Part  5.  as 
STAs  are  formatted  like  the  STARs  (B1 1 .  050). 

Integrated  Program  Summary  (IPS)  -  The  purpose  of  the  IPS  is  to  provide  a  succinct  integrated  picture 
of  the  program  status  for  use  by  the  MDA  and  supporting,  and  review  forums.  It  highlights  the  status  of 
critical  areas  and  plans  for  future  acquisition.  At  MS  I.  the  IPS  shall  summarize  the  results  of  Phase  0. 
CE&D.  When  writing  the  IPS  the  project  team  needs  to  identify  and  provide  the  following  information: 

(a)  The  most  promising  concept(s)  to  be  carried  into  Phase  I,  Demonstration  and  Validation,  for 
demonstration  and  further  development,  and  the  reasons  for  elimination  of  aKemative  concepts. 

(b)  The  risk  reduction  efforts  to  be  accomplished  during  Phase  I. 

(c)  The  trade-off  decisions  to  be  made  for  MS  I.  and  recommended  to  be  made  for  MS  II,  by  the 

MDA. 

(d)  The  design  alternatives  and  trade-offs  to  be  evaluated  during  Phase  I. 

(e)  A  summary  of  the  program  life-cycle  cost  estimate,  irxjependent  cost  estimate,  affordability 
assessment  and  proposed  concept  baseline. 

(f)  The  DoD  Component  proposed  project  acquisition  strategy  and  any  proposed  waivers. 

(g)  The  ASR  discusses  the  basic  acquisition  strategy  being  pursued.  As  part  of  the  IPS,  it 
summarizes  the  entire  planned  program  stmcture  from  Demonstration  and  Validation  through  Production 
and  Deployment.  Requests  for  Proposals  (RFPs)  for  the  DenWal  phase  may  not  be  released  until  the 
MDA  h^  approved  the  ASR.  The  ASR  is  not  to  be  confused  with  the  Acquisition  Plan  (AP)  which 
describes  the  acquisition  strategy  only  for  the  current  phase.  The  ASR  should  discuss  the  transition  of 
critical  technologies  in  technology  demonstration  programs  to  prototypes  and  engineering  development 
models,  plans  for  reducing  risk,  nondevelopment  items,  evolutionary  acquisition,  and  preplanned  product 
improvements  in  the  context  of  the  operational  requirements  and  the  management  approach  to  tli« 
acquisition. 

The  IPS  is  a  statutorily  imposed  requirement  prepared  by  the  project  manager.  The  final  IPS  approved 
by  the  SAE  will  be  submitted  to  the  Defense  Acquisition  Board  (DAB)  Executive  Secretary  no  later  than 
10  working  days  prior  to  the  DAB  Committee  review. 

The  IPS  concept  will  be  used  by  the  DoD  Component  MDA  for  ACAT  1C,  II,  III  and  IV  programs; 
however,  the  documentation  content  should  be  appropriately  tailored  for  ACAT  II,  III  and  IV  programs. 
DoD  5000.2M,  Part  4,  contains  preparation  procedures  and  format  (D58). 

Program  Ufe  Cycle  Cost  Estimate  -  Documents  the  project  teams  life  cycle  cost  estimate  of  the 
project.  Used  by  the  MDA  along  with  the  Cornponent  Cost  Analysis  (CCA)  to  determine  the  acquisition 
program  baseline  cost  estimate  and  affordability  of  the  program.  This  plan  is  prepared  by  the  project 
manager.  DoD  5000.2M,  Part  1 5  contains  preparation  procedures  and  format  (D71 ). 

Acquisition  Program  Baseline  Agreement  (APB)  -  Documents  the  cost,  schedule,  and  performartce 
baselitte  agreemertt  between  the  MDA  and  project  team.  Prepared  by  the  project  team.  DoD  5000.2M, 
Part  14,  contains  preparation  procedures  and  format  (D51). 

Test  and  Evaluation  Master  Plan  (TEMP)  -  Lists  the  critical  developmental  test  and  operational  test 
objectives  and  outlines  the  testing  and  evaluation  approach  and  methodology.  Prepared  by  the  project 
team.  DoD  5000.2M,  Part  7  contains  preparation  procedures  arxf  format  (D^). 
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Component  Cost  Analysis  (CCA)  -  Documents  the  Air  Force  Independent  Life-Cycle  Cost  Estimate. 
Prepared  by  the  Air  Force.  OoD  5000.2M.  Pad  1 5  contains  preparation  procedures  and  format  (B21 ). 
Cost  and  Operational  Effectiveness  Analysis  fCOEAL  Analyzes  the  comparative  cost-effectiveness  of 
alternatives  at  MS  I  and  II.  At  MS  III  and  IV  it  is  updated.  Prepared  by  an  indeperxlent  Analysis  Activity. 
DoD  5000.2M.  Pad  8  and  AFMCP  73-1  contains  preparation  procedures  and  format  (C21 ,  C25,  D48). 

Detenss  toitslligsnce  Agency  (DIA)  Intelligence  Report  -  Validates  the  basis  for  the  threat  in  the 
Mission  Need  Statement  (MNS)  and  the  STAR.  Prepared  by  the  DIA  for  ACAT  ID  programs  (AS). 

Intelligence  Report  -  Validates  the  basis  for  the  threat  in  the  MNS  and  the  STA.  Prepared  by  the  Air 
Force  Intelligence  Command/Agency  (66). 

Joint  Requirements  Oversight  Council  (JROC)  Assessment  -  Verifies  the  need  and  confirms  that  the 
proposed  performance  objectives  and  thresholds  to  be  contained  in  the  program  baseline  satisfy  the 
operational  need.  Prepared  by  the  JROC  (A16). 

Integrated  Program  Assessmerrt  (IPA)  -  Summarizes  the  irKfependent  assessment  of  the  project. 
Identifies  critical  areas,  issues  and  recommendations  for  the  MDA.  Uses  the  same  format  as  the  IPS 
Prepared  by  the  Defense  Acquisition  Board  (DAB)  committee  staff  specialist  for  the  committee 
chairman's  signature.  It  represents  committee  findings  for  DAB  designated  programs  or  documents  the 
results  of  the  committee  review  (A21). 

Independent  Cost  Estimate  (ICE)  Report  -  Documents  the  OSD  Cost  Analysis  Improvement  Group 
(CAIG)  Assessment  of  the  Air  Force  Independent  life-cycle  cost  estimate  (CCA)  and  provides  the  OSD 
CAIG  cost  position  on  the  program.  Pref  .red  at  the  OSD  level  by  Program  Analysis  and  Evaluation 
(PA&E)  (A17). 

Acquisition  Decision  Memorandum  (ADM)  -  Provides  the  decisions  of  the  MDA  (including  approval  u; 
the  ASR  if  not  approved  prior  to  the  MS)  and  the  exit  criteria  for  the  next  phase  of  the  project.  Prepared 
by  DAB  Executive  Secretary  for  ACAT  ID  programs.  Prepared  by  AFAE’s  Staff  Executive  Secretary  for 
ACAT  1C  programs  (A22). 

Integrated  Weapon  System  Master  Plan  (IWSMP)  -  This  plan  addresses  both  the  acquisition  phase 
and  the  evolution  and  sustainment  phase  of  a  weapon  system.  The  IWSMP  will  define  the  weapon 
system  evolution  throughout  the  system  life  cycle.  It  will  be  agreed  to  by  the  developer/supporter  and 
the  customer  and  will  allow  coordinated  budgeting  and  tradeoffs  to  be  made  with  full  knowledge  of  what 
is  forecasted  for  the  future.  IWSMP  is  required  by  AFR  400-3,  Weapon  System  Program  Management, 
Jun  89.  It  has  been  recommended  that  the  IWSMP  be  completed  at  MS  I  and  should  continue 
throughout  the  life  of  the  project.  POC  is  AFMC/XRM,  DSN  787-7596. 

Systems  Engineering  Management  Plan  (SEMP)  -  A  concise  top  level  technical  management  plan  for 
the  integration  of  all  systems  engineering  activities.  For  plan  development  see  DODI  5000.2,  Part  6; 
MIL-STD-499B  (draft).  Systems  Engineering,  6  May  92  (D20B,  D55). 

Systems  Engineering  Master  Schedule  (SEMS)  -  A  top-level  process  control  and  progress 
measurement  tool  to  ensure  completion  of  identified  accomplishments.  The  SEMS  accomplishments, 
with  their  sujjporting  criteria,  shall  include  those  necessary  to  provide  critical  technical  inputs  and 
decision  data  into  engineering  (technical)  arxJ  project  decision  points,  demonstrations,  reviews  and  other 
identified  events.  For  SEMS  development  see  MIL-STD-499B  (draft),  Systems  Engineering,  6  May  92 
(D20B,  D55). 

Risk  Management  Plan  (RMP)  -  Defines  how  risk  analysis  will  be  performed.  The  purpose  of  the  risk 
analysis  is  to  anticipate  the  significant  things  that  could  go  wrong,  develop  contingency  plans  in  case 
they  do  go  wrong,  and  estimate  the  cost  and  schedule  impact  for  each  area  of  risk.  For  plan 
development  see  DoD  Directive  5000.1 ,  Defense  Acquisition,  Part  1  (D37B,  D55). 
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Program  Prolaction  Plan  (PPP)  -  Identifies  essential  project  information,  technology  and  systems  to  be  a 

protected.  It  creates  a  management  plan  which  outlines  the  measures  that  need  to  taken  by  the  i 

project  manager  to  protect  the  system  throughout  the  acquisition  process.  For  plan  development  see 
DoD  Instruction  5000.2,  Part  5. 

Irrtegrated  Logistics  Support  Plan  (ILSP)  -  Describes  the  concepts,  resource  requirements,  tasks, 

schedules,  arxl  subordinate  plans  associated  with  each  Integrated  Logistics  Support  (ILS)  element.  The 

ILS  effort  erKX>mpasses  the  following  elements:  maintenance  planning;  manpower  and  personnel: 

supply  support;  support  equipment;  technical  data;  training  and  training  support:  computer  resources  ' 

support:  facilities:  packaging,  handling,  storage,  and  transportation;  design  interface.  For  plan 

development  see  AFLC/AFSC  Pamphlet  800-34,  Acquisition  Logistics  Management,  Chapter  10, 13  Apr 

87;  AFR  800-8,  Integrated  Logistics  Support  (ILS)  Program,  Atch  5,  Jun  86  (C19.  D20B). 

Pollution  Prevention  Action  Plan  (PPAP)  -  This  is  a  new  plan  to  be  incorporated  into  system 

milestones.  The  plans  major  objectives  are  to  show  how  the  Air  Force  will:  • 

*  reduce  the  use  of  hazardous  materials  in  new  and  existing  weapon  systems 

*  reduce  the  use  of  hazardous  materials  and  waste  generation  at  installations  and  Government 

Owned  Contractor  Operated  (GOCO)  facilities 

*  acquire  state-of-the-art  pollution  prevention  technologies 

*  apply  new  technology  to  pollution  prevention,  from  outside  or  from  Air  Force  research  I 

*  establish  investment  strategy  to  fund  the  pollution  prevention  program. 

The  policy  tor  the  Air  Force  ban  on  purchases  of  Ozone  Depleting  Chemicals  (ODCs)  implements  the 
National  Defense  Authorization  Ac;  for  Fiscal  Year  1993,  Title  III,  Section  326  (Public  Law  102-484  policy 
on  ODCs).  EHective  January  1 , 1993  the  Air  Force  instituted  policy  on  the  purchase,  use,  and 

management  of  controlled  ODCf  The  DFARS  and  AFFARS  on  implementing  Ozone  Depleting  f  | 

Substance  (ODS)  restrictions  and  purchase  bans  became  official  through  Air  Force  Acquisition  Circular 

(AFAC)  92-29, 27  May  93.  The  most  serious  implication  to  the  SPOs  from  these  regulations  are  the 

following  requirements;  Original  contracts  in  excess  of  $10  million  in  value,  with  modifications  or 

extensions  extending  1  year,  initiated  after  1  Jun  93  must  be  evaluated  for  the  elimination  of  ODS.  The 

evaluation  must  be  carried  out  within  60  days.  No  further  modification  may  be  made  until  the  evaluation 

IS  complete.  In  the  absence  of  additional  guidance,  many  programs  may  slip  while  meeting  these  > 

requirements.  ASC/EM  has  highlighted  these  SPO  concerns  to  the  AFMC  Pollution  Prevention  IPT. 

Pollution  prevention  will  be  institutionalized  into  acquisition  by  the  end  of  1994.  (See  Air  Force  Chief  of 
Staff  memo,  Air  Force  Ban  on  Purchases  of  Ozone  Depleting  Chemicals  (ODCs)  -  ACTION 
MEMORANDUM,  dated  7  Jan  93  and  ASC  Environmental  Protection  Committee  briefing,  15  Jan  93). 

Nuclear  Certification  Plan  (NCP)  (if  necessary)  -  This  plan  provides  overall  guidance  and  policy 

concerning  the  nuclear  certification  aspects  of  the  project  (if  applicable).  It  identifies  nuclear  certification  * 

and  safety  activities  that  must  be  accomplished,  arid  identifies  major  contributors  and/or  responsibilites 

of  the  participants  in  the  nuclear  certification  and  safety  projects  It  serves  as  an  integrated,  cohesive 

plan  to  accomplish  the  required  nuclear  certification  tasks.  For  plan  procedures  see  AFR  122-1 ,  The  Air 

Force  Nuclear  Weapon  Surety  Program  and  ASC/ENS  Nuclear  Certification  Handbook,  Feb  87. 

Cost  Analysis  Requirements  Description  (CARD)  -  The  CARD  describes  the  complete  program  and  • 

will  be  used  as  the  basis  on  which  the  project  office  and  Air  Force  cost  analysis  teams  prepare  the 
program  life  cycle  cost  estimates.  For  plan  procedures  see  DoD  5000.4-M  (D52). 

The  Program  Management  Plan  (PMP)  -  Certain  nonmajor  programs  may  use  a  PMP  to  replace  all  the 

functional  plans,  but  the  PMP  is  generally  not  used  on  major  programs.  This  plan  shows  the  integrated 

time-phased  tasks  and  resources  requir^  to  accomplish  each  task  specified  in  the  PMD.  • 
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SyslMn  Security  Master  Plan  (SSMP)  -  Outlines  the  procedures  and  actions  required  to  design, 
develop,  manufacture,  and  deploy  a  secure  weapon  system  that  will  inhibit  or  prevent  overt  or  covert 
ground  threat  action.  This  plan  may  be  tailored  into  the  SEMP.  For  plan  procedures  see  MIL-STD-1 785 
(D20A). 
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Computer  Resources  Life  Cycle  Management  Plan  (CRLCMP)  -  The  management  approach, 
decisions,  and  plans  associated  with  computer  resources  is  documented  in  the  CRLCMP.  Computer 
resources  include  hardware,  firmware,  software,  services,  support  services,  supplies,  and  spare  parts. 
This  plan  is  developed  in  conjuction  with  the  ILSP  to  ensure  software  supportability  is  properly  addressed 
during  development.  The  plans  will  cross-reference  each  other.  For  plan  procedures  see  DoD  5000.2, 
Part  6. 
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1.  ELEI/ENT:  A1.  TBS  0.1. 1.1  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  National  Defense  Planning 

3.  ELEMENT  OWNER(S):  The  President  of  the  United  States 
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4.  ELEMENT  STAKEHOLDER(S):  The  President  of  the  United  States.  Chairman  of  the  Joint  Chiefs  of 
Staff  (CJCS),  the  Office  of  the  Secretary  of  Defense  (OSD),  theater  commanders-in-chief  (CINCs),  the 
Under  Secretary  of  Defense  for  Acquisition  (USD(A)),  Secretary  of  the  Air  Force  (SAF),  and  the  Chief  of 

Staff  of  the  Air  Force  (CSAF).  • 

5.  REQUIREMENT:  DODD  5000.1,  Part  2.  paragraph  B.2 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  To  relate  the  President's  guidance  on  national  security  interests  and  strategies  and  • 

the  use  of  military  resources  to  protect  these  national  interests. 

b.  Objectives:  To  formulate  the  nation's  defense  plans  that  would  best  utilize  military  resources 
to  protect  national  interests. 

7.  DESCRIPTION:  The  President,  with  input  from  the  Natk>nal  Security  Council,  issues  the  National  • 

Security  Strategy  of  the  United  States,  which  provides  guidance  on  national  security  interests  and 

strategies.  The  CJCS  reviews  the  Presidential  guidance  arxf  formulates  the  use  of  military  resources  to 
protect  these  national  interests.  The  CJCS  provides  his  assessment  in  the  Chairman's  Program 
Assessment  (CPA)  document,  which  initiates  the  Joint  Strategy  Review  (JSR)  --  a  process  for  gathering 
information,  raising  issues,  and  integrating  strategy  and  operational  planning  with  program  assessments. 

The  Chairman's  Guidance  (CG)  document  is  the  final  product  of  this  review,  which  provides  top-down  ^ 

guidance  to  the  Joint  Staff  and  information  to  OSD,  CINCs  and  other  members  of  the  JCS  regarding  the 

framework  for  building  the  National  Military  Strategy  Documem  (NMSO).  The  NMSD  is  a  JCS  document 

that  recommends  military  strategy  and  fiscally-constrained  force  structure  to  the  President,  National 

Security  Council,  and  OSD.  The  NMSD  is  issued  in  the  summer  of  odd-numbered  years  and  is  a  major 

input  to  the  formulation  of  the  OSD's  Defense  Planning  Guidance  (DPG).  The  DPG  outlines  OSD's 

strategic  plan  for  the  development  and  employment  of  future  forces  and  is  issued  in  late  fall  of  odd- 

numbered  years.  The  JCS  also  puts  together  the  Joint  Strategic  Capabilities  Plan  (JSCP),  which  * 

contains  guidance  to  the  CINCs  and  Senrice  Chiefs  for  the  accomplishment  of  military  tasks  in  the  near 

term  (2  years),  given  their  service's  capabilities  and  attributes.  With  these  inputs,  the  CINCs  produce 

regional  and  global  plans  and  strategies  tasking  the  seryices  with  specifk.  missions  and  objectives,  and 

the  USD(A)  identifies  major  mission  areas  requiring  miliary  capabilities  to  be  developed  to  meet  mission 

deficiencies.  Studies  and  analysis  organizations  utilize  these  documents  to  update  their  campaign-level 

scenario  databases  so  that  their  analyses  are  based  on  current  global,  national,  and  regional  strategies.  B 

The  service  branches  use  these  overall  defense  strategies  and  guidance  to  formulate  their  own 

strategies  and  guidance  that  best  utilize  their  resources  to  protect  national  interests  (B1). 
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8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  Receipt  of  the  President's  National  Security  Strategy 

b.  Exit:  Publication  of  the  Defense  Planning  Guidance 

9.  KEY  INPUTS/OUTPUTS: 

a.  Input:  National  Security  Strategy  of  the  United  States 

b.  CXitputs:  National  Military  Strategy  Document 

Defense  Planning  Guidance 
Joint  Strategic  Capabilities  Plan 

10.  KEY  REFERENCES:  Air  Force  Instruction  10-601,  paragraph  1.1.1 

11.  IMPLEMENTATION  TOOLS:  None  identified 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  President's  National  Security  Strategy  is  published  every  other  year, 
consistent  with  the  Program  Objective  Memorandum  (POM)  cycle. 

b.  CONSTRAINTS:  None  identified. 

c.  RESOURCES:  AFMC/XP  and  AFMC/XR  are  on  the  distribution  list  for  these  documents. 

d.  LESSONS  LEARNED:  None  identified. 

e.  BEST  PRACTICES:  None  identified. 

f.  TRAPS:  None  identified. 
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1.  ELEMENT:  A2,  TBS  0.1. 6.2.1  (IFC  93-3) 

2.  ELEMENT  TITLE:  Intel  Conununity  Threat  Information 

3.  ELEMENT  OWNER<S):  Defense  Intelligence  Agency  (DIA),  National  Security  Agency  (NSA),  and 
Central  Intelligence  Agency  (CIA) 

4.  ELEMENT  STAKEHOLOER(S):  HQ  USAF/IN.  HQ  AFISAriNA.  HQ  USAF/XOR.  SAF/AQ, 
ASC/NAIC/TIA 

5.  REQUIREliKNT: 

a.  DOO  Directive  5000.1,  Defense  Acquisition,  23  Feb  91 ,  Part  1 .  This  directive  addresses  the 
purpose  of  intelligence  threat  assessments. 

b.  DIAR  55-3,  Intelligence  Support  for  Defense  Acquisition  Process,  30  Mar  92,  PartlO.  This 
regulation  describes  threat  development  procedures. 

c.  AFR  200-13,  Intelligence  Support  to  the  Requirements  and  Acquisition  Processes,  Jul  92. 
This  regulation  states  the  Air  Force  policy  for  identifying  and  acquiring  intelligence  to  support  the  Air 
Force  requirements  and  acquisition  processes. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  production,  review,  and  validation  of  Intelligence  information  in  support  of 
defense  acquisition  programs. 

b.  Objectives:  To  ensure  the  effectiveness  of  each  proposed  system  within  its  intended  threat 
environment  during  its  expected  lifetime. 

7.  DESCRIPTION: 

a.  The  intelligence  community  (DIA,  NSA,  CIA)  is  responsible  for  producing  a  wide  variety  of 
documents  addressing  threat  information  to  determine  if  current  military  capabilities  are  sufficient  to 
meet  the  envisioned  threat  scenario.  It  is  through  this  information  that  threat  based  deficiencies  are 
discovered,  and  needs  for  intproved  capability  are  corx:eived.  Mission  needs,  and  any  resulting  defertse 
acquisition  programs,  are  based  on  current  authoritative  threat  information. 

b.  National  Defense  Planning  (A1 )  relates  the  President's  guidance  on  national  security  interests 
and  strategies  to  use  military  resources  to  protect  these  national  interests.  The  Defense  Planning 
Guidance  (DPG)  outlines  the  OSD  strategic  plan  for  the  development  and  employment  of  future  forces. 
OSD  and  the  Chairrrtan  of  the  Joint  Chiefs  of  Staff  ((}JCS)  produce  documents,  most  notably  the 
National  Military  Strategy  Document  and  the  DPG,  providing  guidance  to  theater  commanders-in-chief 
(CINCs)  and  the  military  Services.  Air  Force  Planning  Guidance  (B1 )  further  relates  the  President's 
guidance  on  national  security  interests  and  OSD's  DPG  to  Air  Force  strategies  to  use  resources  to 
protect  these  national  interests. 

c.  The  startir^  point  for  threat  development  is  a  variety  of  baseline  documents  which,  as  a 
group,  address  the  period  out  1 0  and  20  years  in  the  future.  The  documents  may  include  forecast  threats 
in  broad  mission  areas,  as  well  as  a  number  of  nx>re  detailed  capability  projections  in  specialized  areas. 
Some  documents,  such  as  the  Defense  Intelligence  Projections  for  Planning,  Defense  Intelligence 
Assessments  and  Threat  Environment  Projections  (TEPs)  are  produced  by  the  DIA  (for  example,  TEPs 
were  produced  to  support  the  Major  Aircraft  Review  and  the  Major  Warship  Review).  Other  documents, 
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such  as  the  Navy  Pyramid  documents  and  the  Air  Force  Threat  Environment  Descriplions  (TEDs)  (B2) 
are  produced  under  the  DIA-managed  Science  and  Technology  (S&T)  production  program.  In  addition, 
the  Army  intends  to  produce  baseline  threat  products.  For  programs  requiring  action  by  the  Joint 
Requirements  Oversight  Council  (JROC),  the  appropriate  baseline  threat  products  produced  and/or 
validated  by  DIA  will  be  used  to  support  the  Mission  Need  Statement  (MNS)  (C1 2)  and  Milestone  0 
Phase  of  program  development. 

d.  In  summary,  the  intelligence  community  m^es  sure  the  many  aspects  of  intelligerK^  are 
available  to  support  the  acquisition  process.  Threat  information  is  produced  to  support  the  acquisition, 
planning,  programming,  arxt  budgeting  process.  The  DPG  provides  a  broad  overview  of  the  expected 
threat  environment  and  potential  adversaries.  The  baseline  documents  produced  and/or  validated  by 
DIA  are  used  to  support  the  MNS  and  MS  0.  HQ  USAF/IN  ensures  that  special  operations  subjects  are 
encompassed  in  the  baseline  documents  and  produces  many  generic  threat  documents.  Upon  request, 
DIA  will  provide  broad  guidance,  assist  with  incorporation  of  material  from  relevent  documents  produced 
by  other  elements  of  the  Intelligence  Community,  and  review  and/or  valdiate  the  finished  product. 
NAIC/TIA  produce  TEDs  (B2)  for  the  Air  Force  and  the  DoD.  These  baseline  documents  are  written 
using  Intelligence  Community  Threat  Information. 

8  ENTRANCOEXIT  CRITERIA: 

a.  Entrance;  This  element  starts  with  availability  of  Natioruil  Defense  Planning  Guidance  (At). 

b.  Exit;  This  element  is  complete  when  intelligence  information  has  been  produced,  reviewed, 
and  validated  in  support  of  defense  acquisition  programs  to  ensure  the  effectiveness  of  each  proposed 
system  within  its  intended  threat  environment. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  National  Military  Strategy  Document,  Defense  Planning  Guidance,  and  the  Joint 
Strategic  Capabilities  Plan  (At). 

b.  Outputs.  Validated  threat  information  that  can  support  the  development  of  the  TEDs  and  Air 
Force  mission  needs  (B2  and  Cl 2). 

10.  KEY  REFERENCES: 

a.  DODI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb  91 ,  Part  4. 
This  instruction  discusses  intelligence  support. 

b.  AF  Instruction  10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  arxf 
Procedures,  6  Feb  93,  Paragraphs  1.1.1  and  1.1.7.  This  regulation  discusses  national  security 
assessment,  strategy  evolution,  and  threat  assessment. 

c.  U.  S.  Naval  Postgraduate  School  Thesis,  An  Investigation  of  the  Assessment  of  Threat  by 
Chadwick  Hunter  Dennis.  Addresses  threat  assessment.  A  copy  may  be  requested  by  contacting  the 
Wright  Laboratory  Technical  Library,  WL/DOC,  WPAFB,  OH,  DSN  785-7415. 

1 1 .  IMPLEMENTATION  TOOLS:  Defense  Department  policy-makers  depend  on  quality  information. 
An  efficient  sorting  and  filtering  of  information  into  useful  form  is  required.  This  is  where  systems 
analysts  use  their  scientific  approach  and  mathematical  tools  and  their  own  decision  processes.  Thus, 
some  of  the  rrK)st  valuable  threat  information  is  produced  by  systems  analyst  (Ref.  Thesis,  "An 
Investigation  of  The  Assessment  of  Threat"  by  Chadwick  Hunter  Dennis). 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  intelligence  community  (DIA,  NSA,  CIA)  produces  a  wide  variety  of 
documents  addressing  threat  information  on  a  continuing  basis. 

b.  CONSTRAINTS:  The  necessity  of  having  current  valid  threat  information  available  when 
needed  is  a  key  constraint. 

c.  RESOURCES:  One  project  action  officer  may  be  assigned  from  the  project  team  to 
interface  with  the  irrtelligence  community  through  the  Product  Center's  Director  of  Intelligence  (01) 
(ASC/NAIC/TIA  tor  ASC).  This  is  not  a  full  time  job. 

d.  LESSONS  LEARNED:  Early  and  continued  collaboration  among  the  intelligence, 
requirements  generation,  and  acquisition  management  communities  should  be  maintained  to  ensure  the 
timely  availability  of  valid  threat  information. 

e.  BEST  PRACTICES: 

(1)  The  project  team  should  participate  with  the  intelligence  community  in  the 
development  and  implementation  of  long  range  forecasting  methodologies  and  threat  integration 
techniques. 

(2)  The  project  team  needs  to  keep  in  close  touch  with  the  DIA,  HQ  USAF/IN, 
AFtSA/INA,  the  Product  Center  Dl,  and  the  user.  This  er^les  them  to  be  kept  up-to-date  on  changes  in 
the  threat  environment  and  obtain  ^idance  and  recommendations  on  any  new  intelligence  issues  that 
may  apply  to  their  projects. 

•  (3)  Points  of  contact  are  DIA/DTI-AC,  Area  Code  202-373-8312;  HQ  USAF 

AFISA/INAA,  DSN  225-7577;  ASC  Dl.  ASC/NAIC/TIA,  DSN  785-4285. 

f.  TRAPS:  Failure  of  the  project  team  to  evaluate  documentation  such  as  the  TEDs  regularly 
will  result  in  threat  information  that  is  neither  current  nor  accurate.  This  will  impact  the  validity  of  the 
MNS. 
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1.  ELEiCNT:  A4,  TBS  0.1. 9.8.3  (IFC  93-3) 

2.  ELEMENT  TITLE;  Update  POM/BES  ^ 

3.  ELEMENT  OWNER:  Secretary  of  Defense 

4.  ELEMENT  STAKEHOLDER(S);  Comptroller.  OSD,  CINCs.  Joint  Staff.  OSD  StaH,  0MB  Staff. 

Defense  Planning  arxf  Resources  Board.  HO  USAF.  Project  Manager,  ASC/FM,  Operating  Command, 
and  the  AF  PEO. 

5.  REQUIREMENT:  DoD  Directive  7045.14,  The  Planning,  Programming,  and  Budget  System  (PPBS), 

22  May  1964.  Describes  OSD  budget  process. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  purpose  of  this  Program  Objective  Memorandum  (POM)/Budget  Estimate  I 

Submission  (BES)  exercise  is  to  update  lor  create)  the  approved  DoD  financial  planning  documentation. 

For  a  specific  project,  this  represents  the  primary  opportunity  to  obtain  approval  for  the  projected  funding 
requirements. 

b.  Objective;  The  objective  is  for  all  levels  of  review  (Sen/ices,  OSD,  and  Executive)  to 

develop  a  comprehensive  and  integrated  plan  which  supports  the  Defense  Planning  Guidance  (A1 ).  At  I 

the  project  level,  it  should  be  the  objective  of  the  project  office  to  get  the  program  financial  requirements 
approved  at  the  earliest  opportunity  to  prevent  schedule  delays  due  to  funding  availability. 

7.  DESCRIPTION: 

a.  The  development  of  the  OSD  POM  is  the  process  by  which  OSD  reviews  the  resource  . 

requirements  identified  in  the  service  POMs,  and  generates  its  own  position  as  to  the  Sen/ices'  resources  ' 

necessary  to  support  the  Defense  Planning  Guidance  (DPG).  The  resulting  OSD  POM  is  used  to  update 

the  planning  for  the  6  years  contained  in  the  Future  Year  Defense  Program  (FYDP).  After  OSD 

adjustments  are  made  to  the  POM,  the  Services  are  allowed  to  update  and  reprice  the  planning  and  the 

projects  which  were  approved.  This  is  documented  in  the  BES,  which  converts  the  project  oriented 

format  of  the  POM  into  the  appropriation  categories  and  is  a  primary  input  to  the  President's  budget 

submission  to  Congress.  ^ 

b.  The  FYDP  is  the  official  DoD  database  and  document  which  is  a  compilation  of  the  total 
resources  (forces,  manpower,  and  dollars)  programmed  for  DoD,  arranged  by  Major  Force  Program 
(MFP)  and  appropriation.  The  FYDP  projects  6  years  for  all  data  except  forces,  which  extend  an 
additional  3  years.  The  POM  is  the  primary  process  for  updating  this  approved  planning  document.  For 

an  individual  project,  the  POM  represents  an  opportunity  to  get  the  projected  resource  requirements  f 

(D77)  approved. 

c.  OSD  provides  national  security  policy,  as  documented  in  the  draft  DPG  (A1 ),  to  the  Services 
to  start  the  POM  development  process  around  August  in  the  odd-numbered  years  .  The  final  DPG 
should  arrive  in  the  November/December  time  frame.  The  DPG  provides  Secretary  of  Defense 

(SECDEF)  fiscally-constrained  guidance  on  policy,  strategy,  force  planning,  and  resource  planning.  I 

During  this  same  timeframe,  OSD  provides  the  POM  documentation  requirements,  the  POM  Preparation 
Instructions  (PPI)  to  the  Services,  and  based  on  this  direction,  the  Services  provide  their  POM  proposals 
to  OSD  (B5)  on  1  April  of  even  numbered  years. 

d.  After  receipt  of  the  Senrice  POM  submissions,  the  Chairman  of  the  Joint  Chiefs  of  Staff 
(CJCS)  provides  an  assessment  of  the  POMs  to  assist  the  SECDEFs  decisions  on  the  defense  planning. 

This  is  documented  in  the  Chairman's  Program  Assessment  (CPA),  which  provides  an  assessment  of  the 
balance,  adequacy,  capabHities,  and  risks  of  the  Senrice  POMs,  and  recommends  actions  to  improve 
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overall  defense  capability  within  OSD  fiscal  guidance.  In  addition,  after  the  ROMs  are  received,  OSD, 
JCS,  and  the  CINCs  convene  Program  Reviews  to  determine  Service  compliance  to  DPG  arKf  to 
develop  more  cost-effective  alternatives  to  the  Sen/ices'  proposals.  The  project  atternatives  are 
described  arKl  analyzed  in  Issue  Papers  which  are  provided  for  action  to  the  Defense  Planiting  and 
Resources  Board  (DPRB),  which  serves  as  the  SECDEPs  corporate  review  body.  The  DPRB  members 
are  the  Service  S^retaries  and  other  senior  officials  and  is  chaired  by  the  DEPSECDEF.  Any  issues 
that  are  approved  by  the  SECDEF  are  recorded  in  Program  Decision  Memorandums  (PDMs)  and  the 
PDMs  are  used  to  update  the  Senrice's  databases  and  POM  documentation. 

8.  ENTRANCeEXIT  CRITERIA: 

a.  Entrance:  The  POM  activities  in  OSD  start  with  the  receipt  of  the  Service  POM  submissions, 
at  the  first  of  April  of  the  even-numbered  years.  The  OSD  BES  activities  start  in  mid-September  of  the 
even-numbered  years,  upon  receipt  of  the  Service  BES  submissions. 

b.  Exit:  The  OSD  activity  is  completed  with  the  signing  of  the  Program  Decision  Memorandums 
(PDMs)  by  the  Secretary  of  Defense  in  July/August  of  even  years.  The  BES  activity  is  completed  when 
the  signed  Program  Budget  Decisions  (PBDs)/Defense  Management  Review  Decisions  (DMRDs)  are 
incorporated  into  the  Defense  Budget  which  is  then  delivered  to  0MB. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  necessary  information  is  contained  in  the  Defense  Planning  Guidance  (At),  the 
FYDP,  the  POM  Planning  instructions,  the  Service  POM  submissions  (D77,  C9.  B5),  the  Chairman’s 
Program  Assessment  and  the  Issue  Papers  from  the  Program  Reviews. 

b.  Outputs:  The  output  is  the  Program  Decision  Mermrandums  (A9). 

10.  KEY  REFERENCES: 

DoDI  7045.7,  Implementation  of  the  Planning.  Programming,  and  Budgeting  System  (PPBS), 

23  May  84.  Describes  procedures  for  OSD  budget  process. 

AFP  172-4,  The  Air  Force  Budget  Process,  October  1987.  Describes  the  Air  Force  budget 
process. 

11.  IMPLEMENTATION  TOOLS:  The  PPBS  Primer,"  7th  Edition.  Jan  93.  This  document,  while  still 
"draft,"  is  published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and 
provides  a  valuable  description  of  the  Air  Force  and  OSD  budget  processes.  This  is  one  of  the  few 
documents  that  describes  the  current  process,  and  it  does  so  in  detail.  Further,  it  defines  the  activity 
schedule  for  the  development  of  the  FY96  POM.  However,  there  is  not  a  great  deal  of  information  on 
POM  preparation  and  actions  taken  at  the  field  level. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  OSD  POM  activity  begins  after  receipt  of  the  Service  POM  inputs  in  April, 
and  continues  through  August,  with  the  publication  of  the  PDMs.  The  BES  activities  occur  from  August 
through  mid-September,  when  the  approved  documentation  is  delivered  to  OSD. 

b.  CONSTRAINTS:  The  primary  constraints  to  this  activity  are  the  resource  limitations  placed 
on  OSD,  the  program  information  required  from  the  Services  to  support  decision  making,  and  the 
schedule  limitations  inherent  in  the  budget  timetable.  A  second  constraint  is  limited  data  (being  pre- 
Milestone  0)  from  which  to  submit  an  input  that  could  cover  the  next  8  years.  Yet.  if  an  input  is  not 
made,  there  may  not  be  adequate  funding  in  the  future  if  a  project  does  proceed. 


A 


m 


Ar 


•  • 


D-8 


L_J _ t . . t _ •  ^  • _ t _ t_ _ f _ 1- 


Nov  *3 


c.  RESOURCES:  The  POM  deliberations  within  OSD  require  intensive  activity  by  the  Services 
to  answer  questions  and  to  work  issues.  The  Program  Element  Monitor  (PEM)  should  be  a  key  player  in 
working  program  issues,  but  all  participants  in  the  Air  Force  POM  preparation  may  be  involved.  The 
Project  Director  may  be  requested  to  develop  program  alternatives  to  support  the  deltoerations  or 
provide  other  program  data.  The  BES  generation  is  also  an  extensive  exercise,  but  is  more  limited, 
since  it  is  primarily  a  financial  repackaging  and  adjustments  to  the  approved  POM  position.  It  is  not 
uncommon  for  project  office  personnel  to  testify  before  the  OSD  analysts  in  the  BES  reviews.  This 
testimony  can  become  critical  in  the  PBD  analysis. 

d.  LESSONS  LEARKUED:  During  the  OSD  POM  deliberations  and  reviews,  it  is  important  that 
the  project  manager  keep  in  close  contact  with  the  PEM.  This  is  important  to  help  resolve  issues  that 
may  arise,  and  to  ensure  that  he/she  fully  understands  all  the  pertinent  aspects  of  the  project,  and  can 
defend  the  projected  resource  requirements.  Moreover,  the  Project  Office  must  ensure  that  the  PEM  is 
provided  all  program  documentation  needed  to  support  the  program.  The  need  for  consistency  in  the 
data  provid^  cannot  be  over-emphasized. 

e.  BEST  PRACTICES:  After  submission  of  the  POM  package,  the  project  office  should  posture 
itself  to  respond  effectively  to  programmatic  questions,  and  to  generate  quantitative  answers  to  the 
PEMs  requests  to  develop  and  price  out  program  variations  to  the  POM  submission.  The  capability  to 
generate  this  "what-if  information  in  a  timely  (and  quality)  manner  is  important,  since  the  PEM  may  be 
required  to  make  modifications  to  the  Air  Force  POM  requests  in  terms  of  funding  levels,  quantities, 
schedules,  or  other  programmatic  aspects.  If  a  project  office  is  unable  to  provide  the  necessary 
information,  or  not  in  time  to  support  the  decision  makers,  the  project  may  not  be  supported,  or  approved 
with  insufficient  funding  levels.  It  is  not  unusual  for  program  office  personnel  to  try  to  get  invited  to  the 
OSD  reviews. 

f.  TRAPS:  If  this  is  the  first  POM  submission  for  the  project,  the  submission  should  be 
considered  a  "New  Start,"  and  identified  as  such.  There  may  be  additional  documentation  requirements 
and  a  higher  level  of  review  for  these  projects,  since  there  is  no  existing  funding  line.  Due  to  this,  the 
project  office  must  be  especially  prepared  to  defend  project  requirements  and  perform  programmatic 
excursions.  As  more  participation  occurs  in  the  review  process,  the  need  for  consistency  in  the 
information  provided  is  essential  in  order  to  limit  confusion  and  obtain  project  support. 
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1.  ELEMENT:  AS.  TBS  0.2.2.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Validate  MNS  Threat  (OIA) 

3.  ELEMENT  OWNER(S):  Defense  Intelligence  Agency  (OIA) 
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4.  ELEMENT  STAKEHOLDER(S):  HQ  USAF/IN.  HQ  AFIC,  HQ  AFISA/IN,  HQ  USAF/ICO,  NAIC/TIA, 
HQ  USAF/XOR.  SAF/AQ,  Operating  Command,  and  Implementing  CJommand 

5.  REQUIREMENT: 

a.  DOD  Directive  5000.1 ,  Defense  Acquisition,  23  Feb  91 ,  Part  1 .  This  regulation  defines  the 
purpose  of  threat  assessments. 

b.  DOD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91, 

Part  4.  This  regulation  contains  policies  and  procedures  for  the  production,  review,  and  validation  of 
intelligence  support  information. 

c.  DIA  Regulation  55-3,  Intelligence  Support  for  Defertse  Acquisition  Programs,  30  Mar  92, 
Paragraphs  7  thru  10.  This  regulation  defines  the  roles  and  responsibilities  of  the  DIA  and  DoD 
Componertts  in  the  production,  review,  and  validation  of  threat  information  in  support  of  defense 
acquisition  programs. 

6  PURPOSE/OBJECTIVES: 

a.  Purpose;  To  ensure  the  threat  used  to  support  the  Mission  Need  Statement  (MNS)  is  valid. 

b.  Objectives:  To  validate  the  threat  to  be  countered  as  described  in  the  MNS  and  prepare  the 
intelligence  report  in  support  of  the  Defense  Acquisition  Board  (DAB)  Milestone  0  decision  review. 

7  DESCRIPTION: 

a.  The  DIA  is  required  to  validate  threat  documentation,  threat  data  bases,  and  threat 
assessment  procedures  used  in  analyses  leading  to  milestone  decisions  and  system  development.  To 
initiate  validation  of  DAB  threat  documentation,  HQ  USAF/IN  forwards  threat  documents  to  DIA  (B6) 
under  a  covering  merrwrandum  indicating  their  approval.  Threats  prepared  in  support  of  joint  programs 
must  have  other  Component  coordination  prior  to  submission  to  DIA.  Other  DAB  documentation  with 
threat  content  is  forwarded  by  cognizant  DoD  offices.  DIA  review  and  validation  are  based  upon  the 
intended  use  of  the  document  to  support  the  system  acquisition.  The  DIA  review  stresses 
appropriateness  of  the  judgments,  consistency  with  existing  intelligence  positions,  and  logic  of 
extrapolations  from  existing  intelligence.  Upon  receipt  and  incorporation  of  DIA  comments,  HQ  USAF/IN 
forwards  a  letter  to  DIA  certifying  that  the  changes  have  been  made  or  provides  a  written  reclame  with 
justification.  Documents  reviewed  and  validated  have  the  following  statement  in  the  preface:  "The 
Defense  Intelligence  Agency  has  validated  this  document  for  use  in  analysis  supporting  (Project  name) 
Milestone  0  decisions  and  development  activities  taking  place  during  Phase  0."  Where  documents  are 
validated  but  do  not  support  a  specific  program,  the  following  statement  will  be  used;  The  Defense 
Intelligence  Agency  has  validate  this  document  for  use  in  support  of  the  systems  acquisition  process." 
Notification  of  nonvalidation  will  be  provided  to  HQ  USAF/IN  as  soon  as  possible. 

b.  Early  in  the  acquisition  process,  the  user  lead  project  team  is  technically  responsibile  for  all 
aspects  of  the  program.  However,  the  project  team  does  not  turn  DIA  on  to  start  the  ball  rolling.  The 
preparation,  review,  validation,  etc.,  of  threat  issue  papers  and  intelligence  reports  as  part  of  the 
milestone  decision  package  is  automatic.  This  is  an  independent  timing  function  and  sole  responsibiltty 
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Of  OIA.  The  DIA  is  a  permanent  member  of  three  standirtg  DAB  committees  which  are  Strategic 
Systems,  Conventional  Weapons,  and  Command.  Control,  and  Communications.  As  conrunittee 
members  they  know  when  their  documentation  needs  to  be  accomplished.  If  anything  serves  as  a 
catalyst  in  the  pre-milestone  0  phase,  it  is  receipt  of  the  MNS  for  threat  validation.  This  should  not 
relieve  the  project  team  of  the  responsiblity  of  working  closely  with  the  intelligence  community  in 
ensuring  that  threat  issues  are  addressed  in  a  timely  manner  and  that  the  milestone  documentation 
package  is  complete. 

c.  A  written  Intelligerrce  Report  is  provided  by  the  DIA  to  the  Milestone  Decision  Authority  (MDA) 
prior  to  each  mit.'stone  decision  review.  For  Milestone  0,  Concept  Studies  Approval,  the  intelligence 
report  will  confir...  the  validity  of  the  data  base  documents  used  to  define  the  threat  to  be  countered  and 
projected  threat  environment  for  the  MNS.  The  report  is  prepared  by  the  DIA  and  contains  DIA 
independent  judgments  and  comments  in  an  executive  summary  of  the  threat.  It  is  written  by  one  DIA 
staff  officer:  it  takes  approximately  2  weeks  to  write  and  1  week  to  review  and  coordinate.  This  report  is 
submitted  to  the  appropriate  DAB  Acquisition  Committee  Chair  with  copies  to  the  DAB  Executive 
Secretary,  the  JROC  {A6  and  AS),  the  DoD  Component  Acquisition  Executive  (CAE)  (B9),  the  Program 
Executive  Officer  (PEO),  the  Project  Manager,  and  the  DoD  Component  Intelligence  Organization.  This 
report  is  due  no  later  than  10  working  days  prior  to  the  DAB  Acquisition  Committee  meeting. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance.  This  element  starts  when  HQ  USAF/IN  approves  the  threat  content  contained  in 
the  MNS. 


b.  Exit;  This  element  ends  when  DIA  has  validated  the  threat  content  in  the  MNS. 

9  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  key  input  is  the  MNS  (Cl 2). 

b.  Outputs:  The  key  outputs  are  the  validation  of  the  threat  content  in  the  MNS,  and  completion 
of  the  DIA  Intelligence  Report. 

10  KEY  REFERENCES: 

a.  AF  lnstri.ction  1 0-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures, 

1 6  Feb  93,  Paragraph  1.1.7. 

b.  AFSCR  200-3,  Threat  Assessment  Documentation,  5  Apr  85,  Atch  1 , 

1 1 .  IMPLEMENTATION  TOOLS:  The  threat  and  intelligence  databases  consist  of  validated  System 
Threat  Assessment  Reports  (STARs),  Threat  Assessment  Reports  (TARs),  Threat  Planning  Documents 
(TPDs),  Threat  Environment  Descriptions  (TEDs),  approved  Science  and  Technology  (S  &T)  intelligence 
reports,  regulations,  standard  operating  procedures,  and  other  intelligence  data,  such  as  translations  of 
foreign  reports  or  books. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  When  possible,  project  teams  should  prepare  threat  documents,  i.e.,  MNS 
threat,  in  time  to  allow  the  DIA  at  least  2  weete  for  review  and  coordination.  They  should  be  validated  by 
DIA  and  published  2  to  3  weeks  before  the  DAB  or  Air  Force  Systems  Acquisition  Review  Council 
(AFSARC). 
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b.  CONSTRAINTS:  A  key  limitation  is  the  availability  of  current  threat  models  and  scenarios 
that  can  be  used  as  threat  evaluation  tools. 

c.  RESOURCES: 


I 


I 


(1 )  DIA/DTI-AC  is  presently  organized  into  three  groups  which  reflect  their  membership  ^ 

of  three  standing  committees  for  the  DAB.  They  are  grouped  into  Strategic  Systems.  Conventional 
Systems,  and  Command,  Control,  and  Communications.  The  entire  organization  has  26  individuals 
including  analysts  and  administrative  support.  Eight  acquisition  staff  officers  are  designated  to  a  number 
of  acquisKion  programs.  For  Example,  one  staff  officer/analyst  may  serve  on  the  Command,  Control,  ^ 

and  Communications  group  for  all  services  minus  satellites,  white  another  analyst  might  work  Strategic 
Systems,  i.  e..  the  B-2,  the  M-X  Missile,  and  the  Strategic  Defense  Initiative.  The  third  group, 

C^ventbnal  Weapons,  is  subdivided  into  the  three  services,  and  one  person  works  all  Air  Force 
programs. 


(2)  At  least  one  action  officer  should  be  assigned  by  the  project  manager  to  track  the  * 

progress  of  the  DIA  validation  process  and  provide  additional  information  as  requested. 

d.  LESSONS  LEARNED:  Failure  to  review  and  update  threat  assessment  products  at  key 
project  poirrts  can  allow  development  of  ineffective  or  unneeded  weapon  systems  or  may  prevent  a 
project  from  going  forward. 

I 

e.  BEST  PRACTICES: 

(1 )  The  project  team  needs  to  establish  and  maintain  close  cooperation  among  DIA, 

USAF/IN,  AFISA/INA,  the  Product  Center  Director  of  Intelligence  (Dl)  (ASC/NAIC/TIA  for  ASC),  and 

other  intelligence  activities  to  ensure  the  timely  availability  of  validated  threat  information.  ^ 

(2)  Project  team  contributors  to  threat  documentation  need  to  review  the  draft 
intelligence  report  to  ensure  accurate  use  of  their  data.  NAIC  will  review  draft  assessments  for 
completeness,  consistency,  currency  and  accuracy.  To  speed  up  the  validatbn  process,  HQ  AFMC/IN 
and  NAIC  should  review  the  draft  simultaneously.  When  feasible,  HQ  AFMC/IN  will  give  the  Director  of 
Intelligence  (Dl)  Comments  from  each  review  level  via  secure  phone  to  minimize  such  delays. 

(3)  Points  of  contact  for  additional  information  are  HQ  USAF/XORJ,  DSN  225-7107; 

ASC/NAIC/TIA,  DSN  785-4285;  HQ  AFISA/INAA.  DSN  225-7577;  DIA/DTI-AC,  (202)  373-8312. 

f.  TRAPS: 

(1 )  Failure  of  the  project  team  to  evaluate  threat  documentation  regularly  may  result  in  * 

threat  document  information  that  is  neither  current  nor  accurate  which  may  result  in  the  MNS  not  being 

validated. 

(2)  Failure  to  get  DIA  validation  of  a  threat  may  cause  delay  in  MS  0. 


» 


D-13 


L _ t _ 1 _ t _ t _ ^  -- . • _ t 


I 


» 


MmM 


I 


I 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


I 


» 


» 


I 


I 


D-14 


NovU  • 


1.  ELEMENT:  A6.  TBS  0.2.2.4  (IFC93-3) 

2.  ELEMENT  TITLE:  Staff  and  Coordinate  MNS  (JROC) 

3.  ELEMENT  OWNER:  Joint  Requirements  Oversight  Council  (JROC) 

4.  ELEMENT  STAKEHOLOER(S):  JROC.  AF/XOR.  Operating  Command,  AFMC,  and  Participating 
Commands. 

5.  REQUIREMENT:  CJCS  Memorandum  of  Policy  (MOP)  No.  77,  17  Sep  92,  Requirements 
Generation  System  Policies  and  Procedures,  describes  how  the  JROC  implements  their  oversight 
responsibility  tor  the  requirements  generation  system. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Staff  and  coordinate  the  Mission  Need  Statement  (MNS)  through  the  JROC  secretariat 
in  preparation  for  the  JROC  review. 

b.  Objective;  Obtain  a  Service,  CINC  and  joint  staff  coordinated  MNS  that  the  JROC  can  send  to 
the  Defense  Acquisition  Board  (DAB)  Milestone  Decision  Authority  (MDA). 

7.  DESCRIPTION:  The  overall  MNS  staffing  and  coordination  process  begins  at  the  operating 
command  where  the  MNS  is  drafted  (Cl  2  and  C13),  continues  with  Air  Staff  coordination  (B7),  JR(X 
Sen/ice,  CINC,  and  Joint  Staff  coordination  (ACAT I)  (A6),  and  ends  with  either  CSAF  approval  (ACAT 
ll-IV)  or  validation  by  the  JROC  (ACAT  I)  (A8).  The  JROC  will  use  the  latest  DIA  threat  information  to 
ensure  the  threat  used  to  develop  the  MNS  is  valid  (AS).  The  JROC  also  will  review  ACAT  I  MNS  tor 
assignment  of  joint  potential  designator  (i.e.,  potential  for  joint  applicability).  For  ACAT  IMV  MNS, 

f  validation  and  approval  are  done  by  the  Air  Force  with  the  Operating  Command  as  the  validation 

authority  and  the  Chief  of  Staff  of  the  Air  Force  (CSAF)  as  the  approval  authority  (JROC  assistance  may 
be  requested  to  resolve  lead  Service  issues).  This  data  sheet  addresses  the  JROC  portion  of  the  MNS 
staffing  and  coordination  process. 

Validation  confirms  that  a  mission  need  exists  and  cannot  be  satisfied  by  a  nonmateriel  solution. 
Approval  is  the  formal  sanction  that  the  validation  process  is  complete  and  the  need  is  valid.  Approval 
also  indicates  that  the  need  warrants  concept  exploration  studies  tor  a  possible  new  acquisition  program. 
After  approval,  the  MNS  is  forwarded  to  the  MDA  tor  action. 

During  the  AF1 10-601  draft  "for  comment"  and  final  "coordination"  phases,  ACAT  I  MNS  are 
distributed  by  AF/XOR  to  the  JROC  Secretariat  for  colonel  ("for  comment")  level  and  two-star 
("coordination")  level  Service,  CINC,  and  Joint  Staff  review.  After  incorporation  of  comments,  AF/XOR 
submits  the  MNS  to  CSAF  for  approval.  CSAF  then  forwards  a  memorandum  to  the  JROC  requesting 
validation  of  the  MNS.  The  Air  Force  (normally  the  Operating  Command  with  AF/XOR  and  JROC  staff 
assistance)  prepares  the  JROC  briefing,  briefs  the  JROC  Secretariat  2  weeks  prior  to  the  JROC  Review, 
and  briefs  the  JROC  (AS)  30  days  prior  to  the  Defense  Acquisition  Board  (DAB).  The  JROC  process 
concludes  with  a  memo  to  the  Under  Secretary  of  Defense  for  Acquisition  (USDA)  indicating  approval  or 
disapproval  of  the  MNS. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Er^rance:  When  the  draft  "tor  comment"  ACAT  I  MNS  is  distributed  by  AF/XOR  to  the  JROC 
Secretariat  for  Sen/ice,  CINC.  and  Joint  Staff  coordination. 

b.  Exit;  When  the  ACAT  I  MNS  is  staffed  and  coordinated  by  the  JROC  Secretariat. 
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9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  lor  comment*  ACAT I MNS  from  the  Air  Staff  (B7).  A  DIA  Intelligence  report  to 
ensure  the  threat  used  to  develop  the  MNS  will  remain  valid  through  the  milestone  dec^n  (AS). 

b.  Outputs:  A  Service,  CINC,  and  Joint  Staff  coordinated  MNS  that  is  ready  for  JROC  Review  (AS). 
A  briefing  that  has  been  reviewed  by  the  JROC  Secretariat  and  is  ready  for  the  JROC  Review  (AS). 

10.  KEY  REFERENCES: 

a.  AFPD  10-6,  Mission  Needs  and  Operational  Requ^on^s,  19  Jan  93,  Attachment  3,  identifies 
MNS  approval  requirements. 

b.  AF1 10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and  Procedures,  16  Feb  93, 
Attachment  4,  identifies  MNS  staffing  and  coordination  procedures. 

c.  CJCS  MOP-77  (see  Requirement,  paragraph  5) 

d.  JROC  Administrative  Instruction,  JROCM-050-92, 6  Jul  92,  identifies  JROC  procedures  to  be 
used  to  staff  the  MNS. 

11.  IMPLEMENTATION  TOOLS:  None  identified 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  JROC  staffing  and  coordination  are  concunent  with  the  AF1 10-601  draft  *for 
comment*  and  final  *coordination*  phases.  The  JROC  is  briefed  after  the  CSAF  has  approved  the  MNS 
and  has  forwarded  it  to  the  JROC  for  validation. 

45  days  (colonel  level  *for  comment") 

15  days  (Operating  Command  work  comments) 

15  days  (2  star  level  "coordination*) 

15  days  (Operating  Corni*'  -xl  work  comments) 

1 5  days  prior  to  JROC  (pi\  lef  JROC  Secretary  and  resolve  issues) 

Note:  These  timelines  are  optimistic.  Time  for  working  comments  and  obtaining 
coordination  can  take  several  months,  deperding  on  issues  or  other  priorities. 

b.  CONSTRAINTS:  None  identified. 

c.  RESOURCES:  An  OPR  will  be  required  from  the  JROC  staff  to  conduct  the  staffing  and 
coordination  process. 

d.  LESSONS  LEARNED:  This  activity  is  handled  by  the  AF/XOR  OPR  (who  serves  as  the  Air 
Force  JROC  Secretariat)  and  the  JROC  OPR.  The  Operating  Command  is  standing  by  for  comments. 
Prodik '  Center  involvement  normally  would  have  occurred  prior  to  staffing  and  coordination,  hopefully  in 
support  of  the  mission  need  analysis  and  development  of  the  MNS.  If  major  issues  arise  during  this 
activity,  however,  AF/XOR  and  the  operating  command  OPR  should  notify  other  participants  (i.e.. 
Product  Cenrer)  and  plan  for  resolution  as  a  team. 

e.  BEST  PRACTICES:  The  Product  Center  OPR  should  stand  by  and  be  prepared  to  help  the 
Operating  Command  OPR  work  comments.  The  JROC  may  be  interested  in  the  planning  for  Concept 
Exploration  and  Definition  (CE&D).  The  Product  Center  shMid  be  ready  to  provide  this  plan.  Potential 
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DAB  issues  should  be  discussed.  Also,  work  with  the  operating  command  OPR  to  ensure  potential  joint 
needs  are  thoroughly  explored  and  explained. 

f .  TRAPS:  For  the  operating  MAJCOM  OPR.  not  working  with  the  Air  Force  JROC  Secretariat  (in 
AF/XOR)  ahead  of  time  tor  tips  in  writing  the  MNS  and  briefing  the  JROC.  Lay  the  grourxlwotk  tor  a 
smooth  coordination  process  before  you  write  the  MNS. 
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1.  ELEMENT:  A7.  TBS  1.1. 1.5.3  (IFC  93-3) 

2.  ELEMENT  TITLE:  UfxJate  POMmES 

3.  ELEMENT  OWNER:  Secretary  (rf  Defense 

4.  ELEMENT  STAKEHOLOER(S):  Comptroller.  Office  erf  the  Secretary  of  Defense  (OSD),  CINCs, 

Joint  Staff,  OSD  Staff,  0MB  Staff,  Defense  Planning  and  Resources  Board,  HO  USAF,  Project  Manager, 
ASC/FM,  Operating  Command,  and  PEO. 

5.  RECMilREMENT:  DoD  Directive  7045.14,  The  Planning,  Programming,  and  Budget  System  (PPBS), 
22  May  1964.  Describes  OSD  budget  process. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  To  ensure  that  all  funding  is  available  to  support  execution  of  the  plamed  project. 
Initial  Program  Objective  Memorandum  (POM)  wedges  should  be  submitted  or  updated  at  the  earliest 
opportunity. 

b.  Objectives:  To  prevent  possible  schedule  delays  later  due  to  inadequate  funding. 

7.  DESCRIPTION: 

a.  The  development  of  the  OSD  POM  is  the  process  by  which  OSD  reviews  the  resource 
requirements  identified  in  the  Service  ROMs,  and  generates  its  own  position  as  to  the  Services' 
resources  necessary  to  support  the  Defense  Planning  Guklance  (DPG).  The  resulting  OSD  POM  is  used 
to  update  the  planning  for  the  6  years  contained  in  the  Future  Year  Deferrse  Program  (FYDP).  After 
OSD  adjustments  are  made  to  the  POM,  the  Services  are  allowed  to  update  and  reprice  the  fanning 
and  the  projects  which  were  approved.  This  is  documented  in  the  Budget  Estimate  Submission  (BES), 
which  converts  the  project  oriented  format  of  the  POM  into  the  appropriation  categories  and  is  a  primary 
input  to  the  President's  budget  submission  to  Congress. 

b.  The  FYDP  is  the  official  DoD  database  and  document  which  is  a  compilation  of  the  total 
resources  (forces,  manpower,  and  dollars)  programmed  for  DoD,  arranged  by  Major  Force  Program 
(MFP)  and  appropriation.  The  FYDP  prr^ects  6  years  lor  all  data  except  forces,  which  extend  an 
additional  3  years.  The  POM  is  the  primary  process  for  updating  this  approved  planning  document.  For 
an  individual  project,  the  POM  represents  an  opportunity  to  get  the  projected  resource  requirements 
(D20A)  approved. 

c.  OSD  provides  national  security  policy,  as  documented  in  the  draft  DPG  (A1 ),  to  the  Senrices 
to  start  the  POM  development  process  around  /^gust  in  the  odd-numbered  years .  The  final  DPG 
should  arrive  in  the  November/December  time  frame.  The  DPG  provides  the  Secretary  of  Detense's 
(SECDEF)  fiscaHy-constrained  guidance  on  policy,  strategy,  force  planning,  and  resource  planning. 
During  this  same  time  frame,  OSD  provides  the  POM  documentation  requirements,  the  POM 
Preparation  Instructions  (PPI)  to  the  Services,  and  based  on  this  direction,  the  Services  provide  their 
POM  proposals  to  OSD  (B8)  on  1  April  of  even  numbered  years. 

d.  After  receipt  of  the  Services  POM  submissions,  the  Chairman  of  the  Joint  Chiefs  of  Staff 
(CJCS)  provides  an  assessment  of  the  POMs  to  assist  the  SECDEF  decisions  on  the  defense  planning. 
This  is  documented  in  the  Chairman's  Program  Assessment  (CPA),  which  provides  an  assessment  of  the 
balance,  adequacy,  capabilities,  and  risks  of  the  Senrice  POMs,  and  recommends  actions  to  improve 
overall  detense  csqsability  within  OSD  fiscal  guidance.  In  addition,  after  the  POMs  are  received,  OSD, 
JCS,  and  the  CINCs  convene  Program  Reviews  to  determine  Service  compliance  to  DPG  and  to 
develop  more  cost-effective  alternatives  to  the  Senrices'  proposals.  The  project  alternatives  are 
described  and  analyzed  in  Issue  Papers  which  are  provided  for  action  to  the  Defense  Planning  and 
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Resources  Board  (DPRB),  which  serves  as  the  SECDEPs  corporate  review  body.  The  OPRB  is  chaired 
by  the  Deputy  SECDEFand  its  members  are  the  Service  Secretaries  and  other  senior  Service  officials. 

Any  issues  that  are  approved  by  the  SECDEF  are  recorded  in  Program  Decision  Memorandums  (PDMs) 
and  the  PDMs  are  used  to  update  the  Services'  databases  and  POM  documentation. 

e.  While  OSD  is  holding  the  Program  Reviews,  the  Air  Force  cortducts  a  Summer  Review, 
which  consists  of  an  evaluation  of  the  pricing  and  execution  of  the  Air  Force  investment  accounts 
(research  and  development,  procurement,  and  military  cortstruction).  Program  and  financial  information 
from  this  review,  plus  any  PDMs  issued  by  OSD,  and  any  necessary  repricing  of  elements  in  the 
databases,  are  used  to  develop  the  Air  Force  BES,  which  is  submitted  to  OSD.  After  OSD  receipt  of  the 
Services'  BES  packages,  a  joint  Assistant  Secretary  of  Defense  (Comptroller)/  Office  of  Management 
and  Budget  (0MB)  review  is  conducted  to  ensure  the  projects  and  dollars  are  correctly  matched.  The 
final  decisions  are  documented  in  Program  Budget  DecisiorK  (PBDs)  and  Defense  Management  Report 
Decisions  (DMRDs).  The  Services  are  allowed  a  final  opportunity  to  take  exception  to  the  PBDs/DMRDs 
in  the  Major  Budget  Issues  cycle,  arxf  then  the  DEPSECDEF  signs  the  final  PBDs/DMRDs.  This  process 
should  be  complete  in  December,  with  the  submission  of  the  Defense  Budget  to  0MB. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  POM  activities  in  OSD  start  with  the  receipt  of  the  Services'  POM 

submissions,  at  the  first  of  April  of  the  even-numbered  years.  The  project  team  should  take  advantage 
of  any  opportunity  to  input  or  update  the  funding  wedge  of  potential  acquisition  projects.  • 

b.  Exit;  The  OSD  activity  is  completed  with  the  signing  of  the  PDMs  by  the  Secretary  of 
Defense  in  July/August  of  even  years. 

9.  KEY  INPUTS  AND  OUTPUTS; 

•  • 

a.  Inputs;  The  necessary  information  is  contained  in  the  Defense  Planning  Guidance  (A1),  the 
FYDP,  the  POM  Planning  Instmctions.  the  Services'  POM  submissions  (B8,  C15,  C14,  D20A).  the 
Chairman's  Program  Assessment  and  the  Issue  Papers  from  the  Program  Reviews. 

b.  Outputs:  The  output  is  the  Program  Decision  Memorandums  (A9). 

10.  KEY  REFERENCES:  * 

DoDI  7045.7,  Implementation  of  the  Planning.  Programming,  and  Budgeting  System  (PPBS), 

23  May  84.  Describes  procedures  for  OSD  budget  process. 

AFP  172-4,  The  Air  Force  Budget  Process,  Oct  87.  ^ 

11.  IMPLEKKNTATION  TOOLS:  The  PPBS  Primer,"  7th  Edition,  January  1993.  This  document, 
while  still  "draft,"  is  published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air 
Force,  and  provides  a  valuable  description  of  the  Air  Force  and  OSD  budget  processes.  This  is  one  of 
the  few  documents  that  describes  the  current  process,  and  it  does  so  in  detail.  Further,  it  defines  the 
activity  schedule  for  the  development  of  the  FY96  POM.  However,  there  is  not  a  great  deal  of 

information  on  the  POM  preparation  and  the  actions  taken  at  the  field  level.  * 


12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  OSD  POM  activity  b^ins  after  receipt  of  the  Services'  POM  inputs  in 
April,  and  continues  through  August,  with  the  publication  of  the  PDMs. 
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b.  CONSTRAINTS:  The  primary  constraints  to  this  activity  are  the  resource  limitations  placed 
on  OSD,  the  program  information  requir^  from  the  Senrices  to  support  decision  making,  and  the 
schedule  limitations  inherent  in  the  budget  timetable.  A  second  constraint  is  Nmited  data  (being  pre- 
Milestorre  0)  from  which  to  submit  an  input  that  could  cover  the  next  8  years.  Yet,  if  an  input  is  not 
made,  there  may  not  be  adequate  funding  in  the  future  H  a  project  does  proceed. 

c.  RESOURCES:  The  POM  delberations  within  OSD  require  intensive  activity  by  the  Services 
to  answer  questions  and  to  work  issues.  The  Program  Element  Monitor  (PEM)  should  be  a  key  player  in 
working  program  issues,  but  an  participants  in  the  Air  Force  POM  preparation  may  be  involved.  The 
Project  Director  may  be  requested  to  develop  program  alternatives  to  support  the  deiberations  or 
provide  other  program  data. 

d.  LESSONS  LEARNED:  During  the  OSD  POM  deliberations  and  reviews,  it  is  important  that 
the  project  manager  keep  in  close  contact  with  the  PEM.  This  is  important  to  help  resolve  issues  that 
may  arise,  and  to  ensure  that  he/she  futty  understands  all  the  pertinent  aspects  of  the  project,  and  can 
defend  the  projected  resource  requirements.  Moreover,  the  Project  Office  must  ensure  that  the  PEM  is 
provided  ail  program  documentation  needed  to  support  the  program.  The  need  for  consistency  in  the 
data  provided  cannot  be  over-emphasized. 

e.  BEST  PRACTICES:  After  submission  of  the  POM  package,  the  project  office  should  posture 
itself  to  be  able  to  respond  effectively  to  programmatic  questions,  and  to  be  able  to  generate  quantitative 
answers  to  the  PEMs  requests  to  develop  and  price  out  program  variations  to  the  POM  submission.  The 
capabiity  to  generate  this  ’what-if  information  in  a  tim^y  (and  quality)  manner  is  important,  since  the 
PEM  may  be  required  to  make  modifications  to  the  Air  Force  POM  requests  in  terms  of  funding  levels, 
quantities,  schedules,  or  other  programmatic  asptects.  If  a  project  office  is  unable  to  provide  the 
necessary  informatiori,  or  not  in  time  to  support  the  decision  makers,  the  project  may  not  be  supported, 
or  approved  with  insufficient  funding  levels.  It  is  not  unusual  for  program  office  personnel  to  try  to  get 
invited  to  the  OSD  reviews. 
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f.  TRAPS:  If  this  is  the  first  POM  submission  for  the  project,  the  submission  should  be 
considered  a  *New  Start,”  and  identified  as  such.  There  may  be  additional  documentation  requirements 
and  a  higher  level  of  review  for  these  projects,  since  there  is  no  existing  funding  line.  Due  to  this,  the 
project  office  must  be  esproialty  prepared  to  defend  project  requirements  and  perform  programmatic 
excursions.  As  more  participation  occurs  in  the  review  process,  the  need  for  consistency  in  the  B 

information  provided  is  essential  in  order  to  limit  confusion  and  obtain  project  support. 
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1.  ELEIiCNT:  A8.  TBS  0.2.2.6  (IFC  93-3). 

2.  ELEMENT  TITLE:  Conduct  Joint  Requirements  Oversight  Council  (JROC)  Review 

3.  ELEMENT  OWNER(S):  Chairman  of  the  JROC. 

4.  ELEMENT  STAKEHOLOER(S):  Chairman  of  the  Joint  Chiefs  of  Staff;  Vice  Chairman  of  the  Joint 
Chiefs  of  Staff;  Vice  Chief  of  Staff,  United  States  Army;  Vice  Chief  of  Naval  Operations;  Vice  Chief  of 
Staff,  United  States  Air  Force;  and  Assistant  Commandant,  and  United  States  Marine  Corps. 

5.  REQUIREIKNT :  OoD  Directive  5000.1 ,  ’Defense  Acquisition.”  23  Feb  91 .  Part  2,  The  Mission  Need 
Statement  for  major  defense  acquisition  programs  wiH  be  forwarded  through  established  review  channels 
to  the  JROC.  Part  2B  entitled  ’Requirements  Generation  System’  identifies  who  chairs  the  JROC  and 
what  are  the  Councifs  functions. 

6  PURPOSE/OBJECTIVES; 

a.  Purpose;  To  review  ACAT  I's  Mission  Need  Statement  (MNS)  and  confirm  that  each 
identified  mission  need  cannot  be  satisfied  by  a  nonmateriei  solution  (e.g.,  a  change  in  doctrine, 
operational  concepts,  tactics,  training,  or  organization).  The  JROC  also  determines  the  validity  of  the 
identified  mission  need  and  forwards  results  (either  approved  or  disapproved)  to  the  Under  Secretary  of 
Defense  for  Acquisition  (USD(A))  as  support  for  the  Defense  Acquisition  Board  (DAB)  Milestone  0 
review.  Approved  statements  will  be  assigned  a  joint  priority. 

b.  Objectives; 

(1 )  Review  of  any  deficiencies  that  may  necessitate  new  major  defense  acquisition 

programs. 

(2)  Ensure  that  nonmateriel  alternatives  to  satisfying  the  need  have  been  considered. 

(3)  The  JROC  assists  the  Chairman  of  the  Joint  Chiefs  of  Staff  in  ensuring  that  all 
potential  materiel  alternatives  to  acquisition  programs  have  been  considered. 

7.  DESCRIPTION:  At  this  point  in  the  project  the  Mission  Need  Statement  (MNS)  has  been  staffed 
and  coordinated  by  the  JROC  Secretary  at  the  0-6  and  2-star  level.  The  JROC  Secretary  has 
previewed  the  Air  Force  JROC  briefing  and  has  accomplished  service  and  joint  coordination  of  the  MNS 
(A6).  Subsequent  to  the  JROC  Review,  the  validated  MNS  is  forwarded  to  the  USD(A)  for  the  Air  Force 
Systems  Acquisition  Review  Council  (AFSARC)  (B9)  and  DAB  (A9).  A  successful  DAB  will  result  in  an 
Acquisition  Decision  Memorandum  (ADM)  which,  when  issued,  is  the  approval  document  required  to 
proceed  into  Phase  0. 

a.  The  JROC  is  responsible  to  the  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  for  performing 
the  funaions  set  forth  below.  The  Chairman  of  the  JROC  (Vice  Chairman  of  the  Joint  Chiefs  of  Staff 
(VCJCS))  is  the  principal  military  advisor  to  the  CJCS  with  respect  to  military  requirements.  The 
Chairman  of  the  JROC  is  the  final  decision  authority  for  all  matters  brought  before  the  (^ncil. 

b.  The  JROC; 

(1)  Assigns  a  JROC  Secretary  (Director  of  Operational  Plans  and  Interoperability  (J-7) 
Joint  Staff)  to  manage  the  MNS  documentation  (see  Staff  and  Coordinate  MNS  (JROC))(A6). 

(a)  The  JROC  Secretary  will  review  and  coordinate  all  MNSs  that  might  result  in 
the  initiation  of  new  major  defense  acquisition  programs  (Acquisition  /Category  I). 
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(b)  The  JROC  Secretary  delegates  harmonization  for  joint  potential  of  non 
ACAT  ID  MNSs  to  the  sponsoring  Service. 

(2)  Secretariat  includes  the  JRCX>  Recorder  and  other  Joint  Staff  personnel  as 
designated  by  the  Secretary.  The  Secretary  assigns  specific  functions  and  duties  in  support  of  the  JR(X 
Chairman.  JROC  Secretariat's  recommended  processing  procedures  and  time  lirres  for  staffing  a  MNS 
are  described  in  A6. 

(a)  The  JROC  reviews  any  deficiencies  that  may  necessitate  new  major  defense 

acquisition  programs. 

(b)  The  JROC  reviews  the  identified  mission  need  (as  distinct  from  any  potential 
system  or  program),  validates  that  a  nonmateriel  solution  is  not  feasible,  assigns  a  joint  priority  for 
meeting  these  needs  and  forwards  the  MNS,  with  amplifying  recommendations  to  the  USO(A)  for  a 
Milestone  0  decision. 

c.  The  JROC  oversees  the  requirements  generation  process  and  ensures  that  emerging 
performance  objectives  and  thresholds  adequately  address  the  mission  need  at  subsequent  milestones. 

d.  The  AFMC/Project  Manager  shall  only  atterfo  the  JROC  review(s)  if  the  AFMC/Project 
Manager's  attendance  is  requested  by  the  Chairman  and  is  approved  by  the  Service  Acquisition 
Executive. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  Can  enter  wl  .en  you  have  a  Service  and  Joint  Staff  coordinated  Chief  of  Staff  of 
Air  Force  (CSAF)  approved  MNS  and  Air  Force  JROC  briefing  (A6).  The  data  that  will  result  from  this 
block  are  a  record  of  the  MNS  staffing  and  coordination  that  has  occurred  and  the  Air  Force's  JROC 
briefirig.  The  briefing  must  be  briefed  to  the  JROC  Secretary  2  weeks  prior  to  the  JROC  Review  and  30 
days  prior  to  the  DAB. 

b.  Exit:  Can  exit  when  the  JROC  Chairman  forwards  the  approved  MNS  to  the  DAB  for  a 
Milestone  0  decision. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1 )  Service  and  Joint  Staff  coordinated  MNS  (A6). 

(2)  Air  Force  briefing  for  JROC  Review  and  DAB  (A6). 

b.  Outputs: 

(If  A  JROC  validated  MNS. 

(2)  Memorandum  to  the  Under  Secretary  of  Defense  for  Acquisition  (USD(A))  stating 
approval  and  recommendations  or  to  the  MNS  sponsor  if  disapproved,  along  with  rationale. 


10.  KEY  REFERENCES: 


a.  OoO  Directive  5000.1,  23  Febr  91.  "Defense  Acquisition,' Part  2.  This  regulation  identifies 
the  Chairnian  of  the  DAB  and  identifies,  for  Milestone  0.  the  initial  interface  between  the  requiremertts 
generation  and  the  acquisition  nnanagement  systems. 

b.  DoD  Instnjction  5000.2,  23  Feb  91 ,  "Defense  Acquisition  Management  Policy  and 
Procedures,"  Part  13,  Sections  A  and  D.  Section  A  of  this  directive  contains  the  time  frame  required  by 
the  JROC  to  hold  a  review,  with  representatives  of  the  DoD  Corrponent,  prior  to  the  DAB.  It  al^ 
includes  the  purpose  and  product  of  the  review.  Section  D  identifies  JROC  policies  and  procedures. 

c.  DoD  Manual  5000.2-M,  23  Febmary  1991 .  "Defense  Acquisition  Management  Documentation 
and  Reports,"  Part  2.  This  manual  provides  the  purpose  and  procedures  for  the  MNS. 

d.  Chairman  of  the  Joint  Chiefs  of  Staff  Memorartdum  of  Policy  (MOP)  No.  77, 1 7  Sep  92, 
"Requirements  Generation  System  Policies  and  Procedures."  This  document  assigns  the  oversight 
responsibility  for  the  requirements  generation  system  to  the  VCJCS.  The  VCJCS  is  assisted  by  the 
JROC  and  members  of  the  Joint  Staff.  It  defines  the  role  of  the  JROC  Secretary. 

11.  IMPLEMENTATION  TOOLS: 

Briefing  guide  and  assessment  items  support  the  JROC  assessment.  Administrative  Instmction 
JROCM-050-92,  6  July  1992  (with  revised  Briefing  Guide,  JROCM  030-93,  30  Apr  93),  "Joint 
Requirements  Oversight  Council."  This  instruction  may  be  used  to  clarify  JROC  procedures  that  are 
used  to  process  requirements  staffing  of  the  MNS  in  accordance  with  DoDD  5000.1,  DoDI  5000.2  and 
DoDM  5000.2-M. 

12  PLANNING  GUIDANCE: 

a.  DURATION: 

(1 )  ACAT I  -  Approximately  90  to  1 20  days  (Note:  This  includes  staffing  from  A-6). 

(See  CJCS  MOP  77, 1 7  September  1992.  Appendix  C  for  sequencing.) 

(2)  ACAT  ll-IV  -  Since  CINC  may  develop,  validate,  and  approve  their  own  MNS  in 
conjunction  with  any  assistance  that  they  request  from  their  Service  Component,  it  customary  for  the 
time  to  be  set  by  the  component.  If  JROC  assistance  is  requested,  it  is  for  the  purpose  of  reaving  lead 
Service  issues  only.  (See  CJCS  MOP  77, 17  Sep  92,  Appendix  C  for  sequencing.) 

b.  CONSTRAINTS:  None  Identified. 

c.  RESOURCES:  None  Identified. 

d.  LESSONS  LEARNED: 

(1)  MNS  must  avoid  advocating  a  specific  system  solution.  The  DoD  5000  acquisKion 
policy  prohibits  a  solution  in  the  MNS.  The  JROC  Chairman  completely  supports  that  position  and  has 
turned  back  MNS  for  being  too  solution  sp^ific.  (Examples:  Carrier  Battle  Group  Airborne  Early 
Warning  Capability  -  JROC  directed  a  rewrite  to  take  out  the  emphasis  on  "organic  AEW/canier-based," 
and  Strategic  Sealift  -  even  though  the  MNS  is  for  a  ship  (sealift)  it  required  numerous  revisions  to 
eliminate  specific  ship  type/design.) 

(2)  The  main  purpose  of  the  JROC  Briefing  Guide  (JROCM-030-93),  30  April  1993,  is  to 
incorporate  lessons  learned.  Things  such  as  dividing  capabilities  into  eight  major  groups  and  developing 
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a  briefing  structure  with  set  subjects  to  be  addressed  in  the  briefing  were  a  direct  resuN  of  what  has  been 

learned  from  earlier  presentations.  The  Briefing  Guide  structure  was  designed  to  answer  the  recurrino 

questions  and  comments  of  the  JROC  Chairman  and  Principals.  ^ 

e.  BEST  PRACTICES: 

(1)  Contact  the  Air  Force  JROC  Secretariat  in  AF/XORJ  for  assistance. 

K  .  ^  ffw  coordination  process  to  be  completed.  Until  the  MNS 

has  been  validated,  funding  is  not  available  and  cannot  be  requested.  * 


/nen\  o*  m  acquisition  policies.  The  Office  of  Secretary  of  Defense 

^  reviews  on  DoD  6000  series  acquisition  policy  and  procecfcires 

CJCS  MOP  77  and  Administrative  Instruction  JROCM-050-92. 


(4)  Keep  the  briefing  material  clear  and  concise. 

(5)  Try  to  identify  Joint  needs  or  focus  on  Joint  potential. 

f.  TRAPS: 


(1)  Advocating  a  specific  system. 


(2) 

and  testing,  but  did 


Trying  to  play  catch  up  on  a  program  that  is  funded  and  moving  fonivard  to  design 
rxjt  go  through  the  requirements  validation  process. 


D-26 


1.  ELEMENT:  A9,  TBS  0.2.2.7/0.2.3.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Conduct  DAB  Milestone  0  Review 

3.  ELEMENT  OWNER(S):  OSD/USO(A) 

4.  ELEMENT  STAKEHOLDER(S); 

Milestone  Review  Board,  i.e.,  Defense  Acquisition  Board  (DAB)  or  Air  Force  Systems  Acquisition  Review 
Committee  (AFSARC).  Milestone  Decision  Authority  (MDA),  Joint  Requirements  Oversight  Committee 
(JROC)  Chariman,  Program  Executive  Officer  (PEO),  Defense  Acquisition  Commander  (DAC)  and 
Operating  Command. 

OSD:  Dir.  API;  DepDir,  ASM:D.TS,  DDR&E;D.SASS.  ASD(C3I):  DASD{C3);  DAB.  CSC;  SSC;  C3IC 

DoD  COMPONENTS: 

Dept  of  Army:  ASA(RDA};  SARD-ZBA 
Dept  of  Navy  ASN(RDA);  Dir,  RE 
Dept  of  Air  Force:  SAF/AQ;  SAF/AQX 

CJCS  (Joint  Staff):  DJ8.  J8/SPED 

Defense  IntelligerKse  Agency  (DIA) 

5.  REQUIREMENT :  DODD  5000.1 ,  Defense  Acquisition  (23  Feb  91 ),  Part  2,  which  describes  the  major 
characteristics  of  the  Acquisition  Management  System,  and  DODI  5000.2,  Defense  Acquisition 
Management  Policies  and  Procedures  (23  Feb  91 )  Part  2  which  establishes  the  general  policies  and 
procedures  for  managing  major  and  nonmajor  defense  acquisition  programs,  and  Part  3,  which  highlights 
the  key  features  and  characteristics  of  the  acquisition  process. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  the  Defense  Acquisition  Board  (DAB)  review  is  to  advise  the  USD(A) 
concerning  a  Milestone  0  decision.  The  actual  decision  is  made  by  the  Milestone  Decision  Authority 
(MDA)  and  is  documented  in  the  Acquisition  Decision  Menwrandum  (ADM). 

b.  Objectives:  The  objectives  of  Milestone  0  review  are  to  1 )  determine  if  a  documented  mission 
need  warrants  the  initiation  of  study  efforts  of  alternative  concepts,  and  2)  identify  the  minimum  set  of 
akemative  concepts  to  be  studied  to  satisfy  the  need. 

7.  DESCRIPTION:  Milestone  0  marks  the  initial  formal  interface  between  the  requirements  generation 
and  the  acquisition  management  systems.  The  Joint  Requirements  Oversight  Oxincil  (JROC)  validated 
Mission  Need  Statement  (MNS)  is  forwarded  to  OSD/USD(A)/API/ASM,  the  office  responsible  for  staffing 
the  MNS  (A8).  The  MNS  is  also  forwarded  to  the  Air  Force  where  it  is  reviewed  by  the  Air  Force 
Systems  Acquisition  Review  Council  (AFSARC)  (B9). 

OSD/USD(A)/API/ASM  (through  staffing  with  the  DAB  principals  and  appropriate  Committee  Chair) 
determines  a  funding  source  and  verifies  that  the  need  has  sufficient  interest  to  continue  processing. 
When  funding  is  available  and  the  intelligence  report  has  been  received,  the  MNS/intelligence  report  is 
forwarded  to  the  Committee  Chair  who  recommends  to  the  USD(A):  1 )  whether  or  not  the  effort  should 
be  considered  a  potential  major  program,  2)  whether  or  not  the  effort  should  be  considered  an  Advanced 
Technology  Demonstration  (ATD)  program,  and  3)  whether  or  not  a  DAB  review  should  be  held.  There 
are  three  separate  committees  which  support  the  DAB:  1)  the  Strategic  Systems  Committee  (SSC),  2) 
the  Conventional  Systems  Committee  (CSC),  and  3)  the  Command.  Control,  Communications,  and 
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InteUigence  Systems  Committee  (C3ISC).  The  committees  are  composed  of  representation  from  each 
of  the  DAB  principals  and  other  members  as  determined  by  the  Committee  Chair. 

The  MNS,  intelligence  report,  funding  information,  etc.,  are  then  compiled  into  a  'read-ahead* 
package  which  is  distributed  to  all  the  Committee  Chairs,  and  a  committee  meeting  is  held  to  make 
recommendations  to  the  DAB.  It  is  the  Committee's  responsibility  to  provide  an  independent  assessment 
of  the  study  project.  The  Committee  will  identify  possible  materiel  alternatives  and  study  efforts  for 
consideration  by  the  DAB  and  will  recommend  exit  criteria  for  Phase  0.  Results  of  the  committee  review 
are  used  by  the  Committee  Chairman  to  complete  a  report  to  the  USD(A)  on  the  merits  of  proceeding 
with  the  Concept  Exploration  and  Development  (CE&D),  proposed  alternatives  for  study  during  Phase  0, 
and  proposed  exit  criteria  for  the  next  acquisition  phase.  The  Committee  report  and  crther  pertinent 
information  are  compiled  into  a  read  ahead  which  is  distributed  to  DAB  members  in  preparation  for  the 
DAB.  The  DAB  Executive  Secretary  sets  the  Committee  Review  and  DAB  Review  dates. 

The  DAB  will  convene  and  evaluate  the  MNS,  intelligence  report,  and  Committee  report  and  make 
recommendations  to  the  USD(A).  After  the  DAB,  theUSD(A)  decision  will  then  be  documented  in  the 
Acquisition  Decision  Memorandum  (ADM).  The  ADM;  1)  defines  and  directs  studies  of  a  minimum  set 
of  materiel  concept  ahemath/es,  2)  identifies  the  lead  organization  or  organizations  for  the  study  efforts 
which  involve  designating  one  or  more  of  the  Military  Departments  or  Defense  agencies  to  corrduct  the 
studies  and  present  the  resuHs  at  the  next  milestone  decision  poirrt,  3)  identifies  the  dollar  amount  and  a 
source  of  funding  for  the  study  efforts  to  be  corxfucted  (the  funding  may  come  from  reprograthming, 
budget  amendment  actions,  or  study  funds  controlled  by  one  or  rmre  of  the  DoD  Components),  and  4) 
establishes  any  exit  criteria  information  or  analyses  that  must  be  presented  at  Milestone  1 .  An  action 
officer  in  OSD/USD(A)/API/ASM  prepares  the  ADM  and  coordinates  it  through  API  and  the  Committee 
Chair.  It  is  then  forwarded  to  the  DAB  members  for  review.  The  ADM  is  signed  by  the  USD(A)  after 
coordination.  The  current  objective  is  to  issue  the  ADM  within  48  hours  of  the  DAB.  Upon  receipt  of  the 
ADM,  AF/XOR  issues  the  Program  Management  Directive  (PMD)  to  initiate  Phase  0  (B10). 

See  Attachment  1  for  a  summary  of  the  MDA  Decision  Process. 

8.  ENTRANCE/EXnr  CRITERIA: 

a.  Entrance;  The  activities  associated  with  this  data  element  can  start  when  a  JROC  validated  MNS 
is  available  and  has  been  forwarded  to  the  DAB  Executive  Secretary. 

b.  Exit;  Activity  for  this  effort  is  complete  when  the  ADM  has  been  approved  and  distributed. 

9.  KEY  INPUTS  AND  OUTPUTS: 


t  I 


a.  Inputs; 


(1)  Validated  MNS 

(2)  DIA  Intelligence  Report 


(3)  Other  documentation  identified  by  the  Milestone  Decision  Authority  or  the  responsible 
committee/review  boards  that  support  the  Milestone  Decision  Process. 

b.  Output;  ADM 
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10.  KEY  REFERENCES: 

a.  DODO  5000.1 ,  Defense  Acquisition  (23  Feb  91).  Part  2,  which  describes  the  major  characteristics 
of  the  Acquisition  Management  System. 

b.  DODI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures  (23  Feb  91 ).  Part  2. 
which  establishes  the  general  policies  and  procedures  for  managing  major  and  nonmajor  defense 
acquisition  programs,  and  Part  3,  which  highlights  the  key  features  and  characteristics  of  the  acquisition 
process. 

1 1 .  IMPLEIIENTATION  TOOLS:  Normal  word  processing,  spreadsheet,  and  chart  software  are 
required  for  the  development  of  Milestone  Decision  Documentatbn.  However,  the  Air  Force  lessons 
learned  and  AFAM  repositories  are  sources  of  lessons  learned  and  Graybeard  wisdom  for 
preparatkxvprocessing  of  documentation. 

12.  PLANNING  GUIDANCE:  There  will  be  an  accountable  person  within  the  office  of  the  DAB 
Executive  Secretariat  at  the  Milestone  Review  Board  to  accurately  document  the  decisions  of  the  board 
so  that  the  ADM  can  be  accurately  written  .  Stay  in  touch  with  this  person  to  monitor  the  results  of  the 
DAB  and  the  status  of  the  ADM.  Also,  becoming  familiar  with  all  players  in  the  Committee  Review 
process  and  all  required  activities  is  recommended  in  order  to  address  concerns  and  hidden  agenda  prior 
to  the  actual  reviews.  In  addition,  discussing  lessons  learned  with  one  or  more  CE&D  efforts  which 
recently  completed  this  activity  would  be  advantageous.  Advance  identification  of  a  funding  source  will 
result  in  a  more  expeditious  processing  of  the  milestone  documentation. 

a.  DURATION:  The  duration  from  validation  of  a  MNS  and  AFSARC  review  (if  required)  to  release 
of  an  ADM  will  vary  for  each  MNS.  Availability  of  funds  has  a  significant  impact  on  the  time  required  to 
release  a  documented  MDA  decision.  When  funds  have  been  identified  (a  sponsor  is  available),  the 
process  is  short.  However,  when  funds  are  not  available,  the  MNS  may  have  to  be  held  pending  funding 
availability  within  the  budget  cycle.  When  a  mission  need  is  identified  as  an  ATD,  Advanced  Research 
Projects  A^ncy  (ARPA)  funds  may  be  required  in  which  case,  the  MNS  will  be  held  until  funds  have 
been  identified. 

The  following  is  a  summary  of  the  time  frame  required  for  various  activities  in  this  process. 


•  i 


Time  frame 


Read-ahead  to  Committee  Members  At  least  2  working  days  prior  to  Committee  Review 


Committee  Review 


Committee  Report 
Preparation  of  the  ADM 
DAB  principals  Review  the  ADM 
USD(A)  Signature  of  ADM 


At  least  1 4  calendar  days  prior  to  DAB  Review 
Within  5  catendar  days  after  the  Committee  Review 
Approximately  1  day 
24  hours  by  regulation 


Within  48  hours  after  DAB  Review 


Processing  time  for  documentation  submittal  is  unknown.  A  MNS  will  be  processed  based  upon  its 
priority  and  funding  availability. 
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Now  IS 


b.  CONSTRAINTS: 

(1)  An  AOM  cannot  be  generated  unless  a  dear  decision  which  can  be  documented  is  available 
from  the  Milestone  Oedsion  Authority  (whether  or  not  a  Review  Board  is  convened). 

(2)  Availability  of  funds  to  start  a  Phase  0  effort  is  usually  the  biggest  constraint  to  the  milestone 
decision. 


c.  RESOURCES: 

(1)  The  DAB  Secretary  (Oiredor,  USO(A)/API/ASM)  documents  the  results  of  the  milestone 
review/d^sion,  arxl  prepares,  coonfinates,  and  distributes  the  ADM  at  milestone  review  authority  level. 
At  least  one  individual  will  be  needed  in  AF/XOR  to  monitor  and  track  adions  and  documents  associated 
with  the  DAB  adivity.  Computers  (and  associated  peripheral  and  software)  and  telephones  are  required 
for  this  irKlividual. 

(2)  Adion  officers  wili  be  required  within  the  Air  Force  (Operating  CotTwnand/Implementing 
Command,  AF/XOR,  and  SAF/AQ)  to; 

--  track  the  status  of  documentation  submitlal, 

--  ensure  appropriate  quantities  are  provided  to  the  corred  agencies  to  follow-up  on  issues, 
and 

-  monitor  status. 


d.  LESSONS  LEARNED:  While  the  ADM  is  supposed  to  be  distributed  within  48  hours  of  the  DAB 
review,  there  have  been  rare  instances  where  it  was  a  matter  of  morrths  before  distribution  occurred. 
Therefore,  if  the  projed  is  time  sensitive,  study  adivities  may  need  to  begin  prior  to  release  of  the  ADM 
and/or  PMD.  The  projed  team  should  determine  the  necessary  adivities  to  work  on  if  approval  is 
delayed,  focusing  on  the  use  of  organic  resources.  The  projed  team  must  assess  the  amount  of  adivity 
that  is  wise  to  proceed  with  until  formal  approval  to  proceed  has  been  given. 

e.  BEST  PRACTICES: 

(1 )  To  prevent  confusion  on  implementation  of  the  decision  of  the  Milestone  Decision  Authority, 
the  ADM  must  be  dear  and  accurate. 

(2)  Make  sure  briefings  cover  issues  and  are  nd  marketing  pitches.  It  is  also  absolutely  essential 
to  elevate  issues  as  soon  as  possible. 

(3)  Close  coordination  with  the  Air  Force  Focal  Point  and  the  Committee  staff  specialist  is  highly 
recommended  to  ensure  that  adequate  copies  are  provided  and  that  documents  reach  appropriate 
individuals  in  time  to  meet  required  due  dates.  Adivities  should  be  monitored  in  order  to  meet 
scheduled  time  frames. 


f.  TRAPS: 

(1)  ADM's  can  be  ambiguous  or  incomplete  on  critical  matters.  Therefore,  it  is  critical  to 
understatid  the  DAB'S  intent  when  using  the  ADM  for  diredion. 
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(2)  Documentation  processing  can  be  delayed  in  the  POM  process  U  a  funding  source  is  not 
ident^. 


(3)  Try  to  limit  the  numbered  alternatives  to  be  studied  in  the  AOM.  Make  sure  the  exit  criteria 
are  explicit,  measurable,  and  precise. 


DECISION  PROCES 

(Attachment  1) 
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1.  ELEMENT:  A10(IFC93-3) 

2.  ELEMENT  TITLE:  Provide  DIA  Threat  Support 

3.  ELEMENT  CmNEfHS):  Oeiense  ln(elligerK»  Agency  (DiA) 

4.  ELEMENT  STAKEHOLOER(S):  HQ  USAF/IN.  HQ  AFIC,  HQ  AFISA/INA,  HQ  USAF/ICO. 

NAIC/TIA,  SAF/AQ,  Operating  Command,  and  Implementing  Command. 

5.  REQUIREMENT: 

a.  DOO  Directive  5000.1 .  Defense  Acquisition.  23  Feb  1991 .  Pan  1 .  This  regulation  addresses 
iraelligence  threat  assessments. 

b.  DOD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures.  23  Feb 

91 .  Pan  4.  This  regulation  addresses  policies  arid  procedures  for  production,  review,  and 
validation  of  intelligence  information  in  support  of  defense  acquisition  programs. 

c.  DIA  Regulation  55-3,  Intelligence  Support  for  Defense  Acquisition  Programs,  30  Mar 

92,  paragraphs  7  and  8.  This  regulation  addresses  background  information  and  DIA  responsUlities. 

6  PURPOSE/OBJECnVES: 

a.  Purpose:  Ensure  intelligence  assessment  documents  are  standardized  and  relatable  to  the 
acquisition  process  and  program  baselines. 

b.  Objectives;  Review  and  validate  intelligence  threat  assessments  used  by  acquisition 
authorities  to  ensure  that  each  proposed  system  developed  is  effective  within  its  intended  threat 
environment. 

7  DESCRIPTION: 

a.  The  DIA,  as  principal  advisor  to  DoD  Components  for  intelligence  and  threat  concerns,  is 
responsible  for  reviewing  and  validating  some  of  the  DoD  component  produced  threat  documents 
relating  to  acquisition  programs.  All  Air  Staff  and  MAJCOM  organizations  should  consult  DIA  through 
AFISA/INA  for  the  appropriate  information  when  beginning  the  Phase  0  study  effort.  Any  threat  or 
intelligence  data  used  in  the  modeling,  analysis  or  Cost  and  Operational  Effectiveness  Analysis  (COEA) 
efforts  should  originate  from  DIA  provided  documerrts. 

b.  The  Concept  Action  Group  (CAG)  (if  formed)  is  the  Phase  0  study  group  that  ensures 
implementing  organizations  have  and  use  approved  models  and  data  bases  for  all  studies  and  analyses. 
In  this  regard  they  are  responsUe  to  notify  DIA  to  develop/update  threat  assessment  documents.  The 
CAG  membership  is  detennined  by  the  lead  MAJCOM  arid  should  include  a  minimum  of  one  DIA 
representative  to  address  inteHigeiice  (threat)  issues  needed  to  achieve  Phase  0  objectives  ( C16). 

c.  Threat  assessments  for  ail  Defense  Acquisition  Board  (DAB)  documents  will  be  system- 
sp^ific.  However,  early  in  the  program,  the  degree  of  specificity  will  depend  upon  the  definition  or 
r^inement  of  the  conce^system  at  the  time  of  threat  pr^ration.  As  the  system  progresses  through  its 
milestones  and  becomes  more  clearly  defined,  threat  assessments  should  become  more  specific.  When 
significant  change  in  the  threat  occurs,  especially  threat  affecting  critical  system  characteristics,  Critical 
lntelligerK:e  Parameters  (CIPs),  and  the  CIP  Tfveat  Status,  validated  threat  assessments  wiH  be  revised 
and  reissued  or  a  change  will  be  developed  and  issued  outside  of  the  normal  update  cycle  associated 
with  critical  program  events.  Revisions  or  changes  will  be  initiated  by  the  responsible  DoD  Component 
and/or  DIA. 
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d.  Adcfilional  support  provided  by  Dl  A  is  as  iottows: 

(1)  Provides  irtdependent  threat  assessments  (utilizing  the  resources  of  the  Science  & 
Technology  (S&T)  Centers  as  needed)  in  order  to  provide  the  material  for  intelligence  reports  which  may 
be  required  to  support  the  DAB. 

(2)  Validates  threat  data  bases,  to  include  the  target  data  base,  and  the  threat 
assessment  procedures  the  DoO  Component  intelligence  commands  or  agencies  wW  use  in  preparing 
system  threat  reports  for  ACAT I  through  IV  programs,  and  highly  sensitive  classified  programs.  While 
OIA  normally  wHI  not  validate  Category  IC  and  Category  II  through  IV  threat  assessments,  if  the  Defense 
Acquisition  Executive  (DAE)  iderttifies  any  project  as  being  of  special  interest,  DIA  win  be  caled  upon  to 
provide  validation  of  threat  assessments  and  further  information. 

(3)  Chairs  the  Threat  Intelligence  Support  Council  (TISC)  and  coordinates  functions  of 
that  body  in  providing  intelligence  support  to  defense  acquisition  projects. 

(4)  Must  be  prepared  to  address  threat  issues  and  concerns  at  DAB  Committee 
meetings.  Submits  draft  System  Threat  Assessment  Reports  (STARS)  to  the  CIA  for  review  and 
comment.  Incorporates  appropriate  CIA  comments  into  the  STAR.  Forwards  CIA  comments  to  the 
coTKemed  DoD  Component  lor  information. 

(5)  Comments  and  provides  data  as  required  to  determine  the  cost  of  unique 
intelligence  support  requirements  contained  in  the  Life  Cycle  Cost  Estirrurte. 

8  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Whenever  requested,  whether  by  the  user  or  the  acquisition  community,  the  DIA 
wiH  provide  support  using  key  data  extracted  from  approved  intelligence  community  threat  information. 

b.  Exit:  The  DIA  will  support  AF/IN  by  reviewing  arxf  validating  threat  documentation  in  support 
of  the  systems  acquisition  process. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  Milestone  0  •  Concept  Studies  Approval  which  marks  the  initial  interface  between  the 
requirements  generation  and  the  acquisition  management  system  ( A9). 

b.  Outputs:  Intelligence  support  to  the  Air  Force  by  providing  input,  review,  and  validation  of 
threat  documentation  as  it  is  initiate  by  the  acquisition  command  between  MS  0  arid  MS  I. 

1 0.  IMPLEMENTATION  TOOLS:  The  Threat  Intelligence  Support  Council  (TISC)  is  the  primary  forum 
used  by  the  DIA  and  the  DoD  Components  to  resolve  issues,  provide  and  obtain  guidance,  and  make 
recommerxiations  to  the  Director,  DIA,  and  the  Senrice  Inteltigence  Chiefs  concerning  intelligence 
support  to  defense  acquisition. 

1 1 .  KEY  REFERENCES:  AFSC  Relation  200-3,  Threat  Assessment  Documentation,  5  Apr  85, 
Attachment  1.  This  regulation  contains  Director  of  Intelligence  responsibilities  and  threat  standardization 
and  review  policies. 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  DOO  policy  requires  that  the  effectiveness  of  a  proposed  concept  or  system 
within  its  intended  threat  environment  be  a  fundamental  concern  of  the  acquisition  effort.  Therefore,  DIA 
threat  support  is  ongoing  through  aH  phases  of  the  systems  acquisition  process. 

b.  CONSTRAINTS:  Limitations  and  restrictions  on  data  flow,  data  bases;  and  resources  (see 
next  paragraph). 

c.  RESOURCES: 

(1)  DIA/OTI-AC  is  presently  organized  irffo  three  groups  which  reflect  their  membership 
of  three  starxling  committees  for  the  DAB.  They  are  grouped  into  Strategic  Systems,  Conventional 
Systems,  and  Command,  Control,  and  Conwnunications.  The  entire  organization  has  26  individuals 
including  analysts  and  administrative  support.  Eight  acquisition  staff  officers  are  designated  to  a  number 
of  acquisition  programs.  For  example,  one  staff  officer/analyst  may  serve  on  the  Command,  Control, 
and  Communications  group  for  all  services  minus  satellites  while  another  analyst  might  work  Strategic 
Systems,  i.  e.,  the  B-2  Bomber,  the  M-X  Missile,  and  the  Strategic  Defense  Initiative.  The  third  group. 
Conventional  weapons,  is  subdivided  into  the  three  services,  and  one  person  would  work  all  Air  Force 
programs. 


(2)  One  project  action  officer  may  be  assigned  from  the  project  team  to  interface  with 
the  intelligence  community  through  the  Product  Center  Director  of  Intelligence  (Dl)  (ASC/NAIC/TIA  for 
ASC).  This  is  not  a  full  time  job. 

d.  LESSONS  LEARNED:  Early  and  continued  collaboration  among  the  DIA  and  the  Air  Force 
Intelligence  community  will  expedite  the  development,  review,  and  validatbn  of  threat  documentation 

f  and  help  to  ensure  its  availability  to  all  concerned  in  a  timely  manner. 

e.  BEST  PRACTICES:  The  project  team  needs  to; 

(1)  Get  the  DIA  to  participate  in  Threat  Steering  Groups  (TSGs)  for  DAB  programs. 
They  must  be  requested  by  AF  Intelligence  Command  or  Agency,  the  project  manager  or  other 
acquisition  authority. 

(2)  Encourage  CIA  participation  when  appropriate. 

(3)  Establish  close  working  relatbnshbs  wffh  AF/IN,  AFISA/INA,  Product  Center  Dl,  and 
other  members  of  the  intelligence  community. 

(4)  For  additional  information  on  DIA  threat  support,  please  call;  HQ  AFISA/INAA,  DSN 
225-7577,  HQ  AFMC/IN,  DSN  785-2869,  ASC/NAIC/TIA,  DSN  785-4285, DIA/DTI-AC,  Area  Code  202- 
373-8312. 


f.  TRAPS:  When  preparing  program  documentation  that  contains  threat  information,  prqect 
teams  must  ensure  threat  data  remains  consistent  in  the  various  documents.  That's  why  early  DIA  threat 
support  is  important.  Failure  to  do  so  may  lead  to  confusion,  misunderstanding,  and  invalidation  by  the 
DIA. 
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1.  ELEMENT:  A12.  TBS  1.2.3.8  3  (IFC  93-3) 

2.  ELEMENT  TITLE:  Update  POM/BES 

3.  ELEMENT  OWNER:  Secretary  of  Defense 

4.  ELEMENT  STAKEHOLOER(S):  Comptroller.  OHice  of  the  Secretary  of  Defense;  CINCs;  Joint  Staff; 
OSD  Staff;  0MB  Staff;  Defense  Planning  and  Resources  Board;  HO  U^F;  MAJCOMs;  Program 
Element  Monitor  (PEM);  Project  Team,  and  Product  Center/FM. 

5.  REQUIREMENT:  DoD  Directive  7045.14,  The  Planning.  Programming,  and  Budget  System  (PPBS), 
22  May  1984. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  POM/BES  exercise  is  to  update  (or  create)  the  approved  DoD 
financial  planning  documentation.  For  a  specific  project,  this  represents  the  primary  opportunity  to  obtain 
approval  tor  the  projected  funding  requirements. 

b.  Objective:  The  objective  is  for  all  levels  of  review  (Services,  OSD,  and  Executive)  to 
develop  a  comprehensive  and  integrated  plan  which  supports  the  Defense  Planning  Guidance  (A1 ).  At 
the  project  level,  it  should  be  the  objective  of  the  project  office  to  get  the  program  financial  requirements 
approved  at  the  earliest  opportunity  to  prevent  schedule  delays  due  to  funding  availability. 

7.  DESCRIPTION:  The  FYDP  (Future  Years  Defense  Program)  is  the  official  DoD  data  base  and 
document.  It  is  a  compilation  of  the  total  resources  (forces,  manpower,  and  dollars)  programmed  for 
DoD,  arranged  by  Major  Force  Program  (MFP)  and  appropriation.  The  FYDP  projects  6  years  for  all 

(  data  except  forces,  which  extend  an  additional  3  years.  For  a  specific  project,  the  POM  represents  an 
opportunity  to  get  the  projected  resource  requirements  documented  in  the  Program  Cost  Estimate  (D47) 
approved. 

a.  Background:  OSD  provides  national  security  policy  as  documented  in  the  Defense  Planning 
Guidance  (A1)  to  the  Services  to  start  the  POM  devefoprnent  process  around  December  in  the  odd- 
numbered  years.  This  provides  Secretary  of  Defense  (SECDEF)  fiscally-constrained  guidance  on  policy, 
strategy,  force  planning,  and  resource  planning.  During  the  same  time  frame,  OSD  provides  the  POM 
documentation  requiremerrts,  the  POM  Preparation  Instructions  (PPI)  to  the  Services,  and  based  on  this 
direction,  the  Services  provide  their  POM  proposals  to  OSD  (B13)  the  following  April. 

b.  The  Program  Objective  Memorandum:  After  receipt  of  the  Services'  POM  submissions,  the 
Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  provides  an  assessment  of  the  POMs  to  assist  the 
SECDEFs  decisions  on  the  defense  fanning.  This  is  documented  in  the  Chairman’s  Program 
Assessment  (CPA),  which  provides  an  assessment  of  the  balance,  adequacy,  capabilities,  and  risks  of 
the  Senrice  POMs,  and  recommends  actions  to  improve  overall  defense  capability  within  OSD  fiscal 
guidance.  In  addition,  after  the  POMs  are  received,  OSD,  JCS,  and  the  CINCs  convene  Program 
Reviews  to  determine  Service  compliance  to  the  Defense  Planning  Guidance,  and  to  develop  more  cost- 
effective  alternatives  to  the  Services'  proposals.  The  program  alternatives  are  described  and  analyzed 
in  Issue  Papers  which  are  provided  for  action  to  the  D^ense  Planning  and  Resources  Board  (DPRB), 
which  serves  as  the  SECDEF's  corporate  review  body.  The  DPRB  members  are  the  Service  Secretaries 
and  other  senior  officials,  and  it  is  chaired  by  the  DEPSECDEF.  Any  issues  that  are  approved  by  the 
SECDEF  are  recorded  in  Program  Decision  Memorandums  (PDMs)  and  the  PDMs  are  used  to  update 
the  Services'  data  bases  and  POM  documentation. 

c.  The  Budget  Estimate  Submission:  While  OSD  is  holding  the  Program  Reviews,  the  Air  Force 
conducts  a  Summer  Review,  which  consists  of  an  evaluation  of  the  pricing  and  execution  of  the  Air 
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Force  investment  accounts  (research  and  development,  procurement,  and  military  construction). 
Program  and  financial  information  from  this  review,  plus  any  PDMs  issued  by  OSD,  and  any  necessary 
repricing  of  elements  in  the  dat2U)ases,  are  used  to  develop  the  Air  Force  Budget  Estimate  Submission 
(BES),  which  is  submitted  to  OSO.  After  OSD  receipt  of  the  Services'  BES  packages,  a  toint  Assistant 
Secretary  of  Defense  (Comptroller)/  Office  of  Managemer^  and  Budget  (0MB)  Budget  Review  is 
conduct^  to  ensure  the  programs  and  dollars  are  correctly  matched.  The  fin^  decisions  are 
documented  in  Program  Budget  Decisions  (PBDs)  and  Defertse  Management  Report  DeciskMis 
(DMRDs).  The  Services  are  allowed  a  final  opportunity  to  t^e  exception  to  the  PBDs/DMRDs  in  the 
Major  Budget  Issues  cycle,  and  then  the  DEPSECDEF  signs  the  final  PBDs/DMRDs.  This  process 
should  be  complete  in  December,  with  the  submission  of  the  Defense  Budget  to  0MB. 

8.  ENTRANCBEXIT  CRITERIA: 

a.  Entrance;  The  POM  activities  in  OSD  start  with  the  receipt  of  the  Services'  POM 
submissions  (B13),  the  first  of  April  of  the  even-numbered  years.  The  OSD  BES  activities  start  in  mid- 
September  of  the  even-numbered  years,  upon  receipt  of  the  Service'  BES  submissions  (B13). 

b.  Exit:  For  the  POM,  the  OSD  activity  is  completed  with  the  signing  of  the  Program  Decision 
Memorandums  (PDMs)  by  the  Secretary  of  Defense  in  July/August.  The  BES  activity  is  completed  when 
the  signed  PBDs/DMRDs  are  incorporated  into  the  Defense  Budget  which  is  then  delivered  to  0MB. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs; 

(1 )  For  the  POM,  necessary  information  is  contained  in  the  Defense  Planning  Guidance 
(A1),  the  FYDP,  the  POM  Planning  Instructions,  the  Services'  POM  submissions  (B13),  the  Chairman's 
Program  Assessment  and  the  Issue  Papers  from  the  Program  Reviews. 

(2)  For  the  BES,  the  required  inputs  are  the  OSD  POM  documentation,  the  Program 
Decision  Memorandums,  and  the  final  Program  Budget  Decisions  and  Defense  Management  Report 
Decisions. 

b.  Outputs; 

(1 )  For  the  POM,  the  outputs  are  the  Program  Decision  Memorandums. 

(2)  For  the  BES,  the  output  is  the  Defense  Budget  documentation  which  is  delivered  to 
0MB,  and  becomes  the  President's  Bud^. 

10.  KEY  REFERENCES:  The  references  below  provide  more  specific  implementation  guidance. 

a.  AFP  172-4,  The  Air  Force  Budget  Process,  Oct  87  -  Describes  the  Air  Force  budget 

process. 

b.  DoDI  7045.7,  Implemerttation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 
23  May  84  -  Describes  the  budget  process  within  the  Department  of  Defense. 

11.  IMPLEMENTATION  TOOLS:  The  PPBS  Primer,"  7th  Edition,  Jan  93.  This  document,  while  still 
"draft,"  is  published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and 
provides  a  valuable  description  of  the  Air  Force  and  OSD  budget  processes.  This  is  one  of  the  few 
documents  that  describes  the  current  process,  and  it  does  so  in  detail.  Further,  it  defines  the  activity 
schedule  for  the  development  of  the  FY96  POM.  However,  there  is  not  a  great  deal  of  information  on 
the  POM  preparation  and  actions  taken  at  the  field  level. 
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12.  PLANNING  GUIDANCE; 

a.  DURATION:  The  OSD  POM  activity  begins  alter  receipt  of  the  Services'  POM  inputs  in  April, 
and  corrtinues  through  August,  with  the  publicaticn  of  the  POMs.  The  OSD  BES  activnies  occur  from  the 
mid-September  receipt  of  the  Services'  BES  inputs  to  December,  when  the  approved  documentation  is 
delivered  to  0MB. 

b.  CONSTRAINTS:  The  primary  constraints  to  this  activity  are  the  resource  limitations  placed 
on  OSD,  the  program  information  required  from  the  Sen/ices  to  support  decision  making,  and  the 
schec&ile  limitations  inherent  in  the  budget  timetable. 

c.  RESOURCES:  The  POM  deliberations  within  OSD  require  intense  activity  by  the  Senrices  to 
answer  questions  and  to  work  issues.  The  Program  Element  Monitor  is  a  key  player  :n  working  program 
issues,  but  all  the  participants  in  the  Air  Force  POM  preparation  may  be  involved.  The  Project  Office 
may  be  requested  to  develop  program  alternatives  to  support  deliberations,  or  provide  other  program 
data.  The  BES  generation  is  also  an  extensive  exercise,  but  is  more  limited,  since  it  is  primarily  a 
financial  repackaging  and  adjustments  to  the  approved  POM  position.  It  is  not  uncommon  for  project 
office  personnel  to  testify  before  the  OSD  analysts  in  the  BES  reviews.  This  testimony  can  become 
critical  in  the  Program  Budget  Decision  (PBD)  analysis. 

d.  LESSONS  LEARNED:  During  the  OSD  POM  deliberations  and  reviews,  it  is  important  that 
the  project  manager  keep  in  close  contact  with  the  Program  Element  Monitor.  This  is  important  to  help 
resolve  issues  that  may  arise,  and  to  ensure  that  the  PEM  fully  understands  all  the  pertinent  aspects  of 
the  project,  and  can  defend  the  projected  resource  requirements.  Moreover,  the  Project  Office  must 
ensure  that  the  PEM  is  provided  all  documentation  needed  to  support  the  project.  The  need  tor 
consistency  in  the  data  provided  cannot  be  over-emphasized. 

e.  BEST  PRACTICES:  After  submission  of  the  POM  package,  the  project  office  should  posture 
itself  to  be  able  to  respond  effectively  to  programmatic  questions,  often  within  a  few  hours,  and  be  able 
to  generate  quantitative  answers  to  the  PEMs  requests  to  develop  and  price  out  program  variations  to 
the  POM  submission.  The  capability  to  generate  quality  "what-iT  information  quickly  (in  a  few  hours)  is 
important,  since  the  PEM  may  be  required  to  make  modifications  to  the  Air  Force  POM  request  in  terms 
of  funding  levels,  quantities,  schedules,  or  other  programmatic  aspects.  If  a  project  office  is  unable  to 
provide  the  necessary  information  in  time  to  support  the  decision  makers,  the  project  may  not  be 
supported,  or  might  be  approved  with  insufficient  funding  levels.  Further,  if  the  project  office  doesnl 
provide  the  data  in  a  responsive  manner,  the  PEM  (or  others)  may  be  forced  to  use  whatever  information 
they  have  at  hand  -  whatever  information  we  can  provide  should  better  than  what  is  generated  without 
our  inputs.  Also,  it  is  not  unusual  for  project  office  personnel  to  try  to  get  invited  to  the  OSD  reviews. 

f.  TRAPS:  If  this  is  the  first  POM  submission  for  the  project,  the  submission  should  be 
considered  a  "New  Start,"  and  identified  as  such.  There  may  be  additional  documentation  requirements 
and  a  higher  level  of  review  tor  these  projects/programs,  since  there  is  not  an  existing  funding  Ime.  Due 
to  this,  the  project  office  must  be  especially  prepared  to  defend  project  requirements  and  perform 
programmatic  excursions.  As  more  participation  occurs  in  the  review  process,  the  need  for  consistency 
in  the  information  provided  is  essential,  to  limit  confusion  and  obtain  OSD  support. 
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1.  ELEMENT:  A1 3.  TBS  1. 2.4.5  5  (IFC  93-3) 

2.  ELEMENT  TITLE:  Update  POM/BES 

3.  ELEMENT  OWNER:  Secretary  of  Defense 

4.  ELEMENT  ST AKEHOLDER(S):  Comptroller,  Office  of  the  Secretary  of  Defense;  CINCs;  Joint  Staff; 
OSD  Staff;  0MB  Staff;  Defense  Planning  and  Resources  Board;  Hq  USAF;  MAJCOMs;  Program 
Element  Monitor  (PEM);  Project  Team,  and  Product  Center/FM. 

5.  REGKJIREMENT:  DoD  Directive  7045.14,  The  Plannirtg,  Programming,  artd  Budget  System  (PPBS), 
22  May  84. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  purpose  of  this  POM/BES  exercise  is  to  update  (or  create)  the  approved  DoD 
financial  planning  documentation.  For  a  specific  project,  this  represents  the  primary  opportunity  to  obtain 
approval  for  the  projected  funding  requirements. 

b.  Objective;  The  objective  is  for  all  levels  of  review  (Services,  OSD,  and  Executive)  to 
develop  a  comprehensive  and  integrated  plan  which  supports  the  Defense  Planning  Guidance  (At ).  At 
the  project  level,  it  should  be  the  objective  of  the  project  office  to  get  the  program  financial  requirements 
approved  at  the  earliest  opportunity  to  prevent  schedule  delays  due  to  funding  availability 

7.  DESCRIPTION:  The  FYDP  (Future  Years  Defense  Program)  is  the  official  DoD  data  base  and 
document.  It  is  a  compilation  of  the  total  resources  (forces,  manpower,  and  dollars)  programmed  for 
DoD,  ananged  by  Major  Force  Program  (MFP)  and  appropriation.  The  FYDP  projects  6  years  for  all 

P  data  except  forces,  which  extend  an  additional  3  years.  F^r  a  specific  project,  the  POM  represents  an 
opportunity  to  get  the  projected  resource  requirements  documented  in  the  Program  Cost  Estimate  (D53) 
approved. 

a.  Background;  OSD  provides  national  security  policy,  as  documented  in  the  Defense  Planning 
Guidance  (A1 ),  to  the  Services  to  start  the  POM  development  process  around  December  in  the  odd- 
numbered  years.  This  provides  Secretary  of  Defense  (SECDEF)  fiscally-constrained  guidance  on  policy, 
strategy,  force  planning,  and  resource  planning.  During  this  same  time  frame,  OSD  provides  the  POM 
documentation  requirements,  the  POM  Preparation  Instructions  (PPI)  to  the  Services,  and  based  on  this 
direction,  the  services  provide  their  POM  proposals  to  OSD  (B16)  the  following  April. 

b.  The  Program  Objective  Merrwrandum;  After  receipt  of  the  Senrices  POM  submissions,  the 
Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  provides  an  assessment  of  the  POMs  to  assist  the 
SECDEFs  decisions  on  the  defense  fanning.  This  is  documented  in  the  Chairman's  Program 
Assessment  (CPA),  which  provides  an  assessment  of  the  balance,  adequacy,  capabilities,  and  risks  of 
the  Service  POMs,  and  recommends  actions  to  improve  overall  defense  capability  within  OSD  fiscal 
guidance.  In  addition,  after  the  POMs  are  received,  OSD,  JCS,  and  the  CINCs  convene  Program 
Reviews  to  determine  Sen/ice  compliance  to  Defense  Planning  Guidartce,  and  to  develop  more  cost- 
effective  alternatives  to  the  Services'  proposals.  The  program  altematives  are  described  and  analyzed 
in  Issue  Papers  which  are  provided  for  action  to  the  Defense  Planning  and  Resources  Board  (DPRB), 
which  serves  as  the  SECDEF's  corporate  review  body.  The  DPRB  members  are  the  Service  Secretaries 
and  other  senior  officials,  and  it  is  chaired  by  the  DEPSECDEF.  Any  issues  that  are  approved  by  the 
SECDEF  are  recorded  in  Program  Decision  Memorandums  (PDMs)  and  the  PDMs  are  used  to  update 
the  Services'  data  bases  and  POM  documentation. 

c.  The  Budget  Estimate  Submission;  While  OSD  is  holding  the  Program  Reviews,  the  Air  Force 
conducts  a  Summer  Review,  which  consists  of  an  evakration  of  the  pricing  and  execution  of  the  Air 
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Force  investment  accounts  (research  and  development,  procurement,  and  military  construction). 

Program  and  financial  information  from  this  review,  plus  any  PDMs  issued  by  OSD,  and  any  necessary 
repricing  of  elements  in  the  databases,  are  used  to  develop  the  Air  Force  Budget  Estimate  Submission 
(BES),  which  is  submitted  to  OSD.  After  OSD  receipt  of  the  Services'  BES  packages,  a  joint  Assistant 
Secretary  of  Defense  (Comptroller)/  Office  of  Management  and  Budget  (0MB)  Budget  Review  is 
conduct^  to  ensure  the  programs  and  dollars  are  correctly  matched.  The  final  decisions  are 
documented  in  Program  Budget  Decisions  (PBDs)  and  Defense  Management  Report  Decisions 
(DMRDs).  The  services  are  allowed  a  final  opportunity  to  take  exception  to  the  PBDs/DMRDs  in  the 
Majo'  Budget  Issues  cycle,  and  then  the  DEPSECDEF  signs  the  final  PBDs/DMRDs.  This  process 
should  be  complete  in  December,  with  the  submission  of  the  Defense  Budget  to  0MB. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  POM  activities  in  OSD  start  with  the  receipt  of  the  Services  POM  submissions 
(B16),  the  first  of  April  of  the  even-numbered  years.  The  OSD  BES  activities  start  in  mid-September  of 
the  even-numbered  years,  upon  receipt  of  the  Service  BES  submissions  (B16). 

b.  Exit:  For  the  POM,  the  OSD  activity  is  completed  with  the  signing  of  the  Program  Decision 
Memorandums  (PDMs)  by  the  Secretary  of  Defense  in  July/August.  The  BES  activity  is  completed  when 
the  signed  PBDs/DMRDs  are  irKx>rporated  into  the  Defense  Budget  which  is  then  delivered  to  0MB. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  For  the  POM,  necessary  information  is  contained  in  the  Defense  Planning  Guidance 
(A1),  the  FYDP,  the  POM  Planning  Instructions,  the  Services*  POM  submissions  (B16),  the  Chairman's 
Program  Assessment  and  the  Issue  Papers  from  the  Program  Reviews. 

(2)  For  the  BES.  the  required  inputs  are  the  OSD  POM  documentation,  the  Program 
Decision  Memorandums,  and  the  final  Program  Budget  Decisions  and  Defense  Management  Report 
Decisions. 

b.  Outputs: 

(1 )  For  the  POM,  the  outputs  are  the  Program  Decision  Memorandums. 

(2)  For  the  BES,  the  output  is  the  Defense  Budget  documentation  which  is  delivered  to 
0MB,  and  becomes  the  President's  Bud^t. 

10.  KEY  REFERENCES:  The  references  below  provide  more  specific  implementation  guidance. 

a.  AFP  172-4,  The  Air  Force  Budget  Process.  Oct  87  -  Describes  the  Air  Force  budget 

process. 

b.  DoDI  7045.7,  Implementation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 
23  May  84  -  Describes  the  budget  process  within  the  Department  of  Defense. 

11.  IMPLEMENTATION  TOOLS:  "The  PPBS  Primer,"  7th  Edition,  Jan  93.  This  document,  while  still 
"draft,"  is  published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  arxf 
provides  a  valuable  description  of  the  Air  Force  and  OSD  budget  processes.  This  is  one  of  the  few 
documents  that  describes  the  current  process,  and  it  does  so  in  detail.  Further,  it  defines  the  activity 
schedule  for  the  development  of  the  fV96  POM.  However,  there  is  not  a  great  deal  of  information  on 
the  POM  preparation  and  actions  taken  at  the  field  level. 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  OSO  POM  activity  begins  after  receipt  of  the  Services'  POM  inputs  in  April, 
and  continues  through  August,  with  the  publication  of  the  PDMs.  The  OSD  BES  activities  occur  from  the 
mid-September  receipt  of  the  Services'  BES  inputs  to  December,  when  the  approved  documentation  is 
delivered  to  0MB. 

b.  CONSTRAINTS:  The  primary  constraints  to  this  activity  are  the  resource  lim^ations  placed 
on  OSD,  the  program  information  required  from  the  Services  to  support  decision  making,  and  the 
schedule  limitations  inherent  in  the  budget  timetable. 

c.  RESOURCES:  The  POM  deliberations  within  OSD  require  intense  activity  by  the  Services  to 
answer  questions  and  to  work  issues.  The  Program  Element  Monitor  is  a  key  player  in  working  program 
issues,  but  all  the  participants  in  the  Air  Force  POM  preparation  may  be  invr^ved.  The  Project  Office 
may  be  requested  to  develop  program  alternatives  to  support  deliberations,  or  provide  other  program 
data.  The  BES  generation  is  also  an  extensive  exercise,  but  is  more  limited,  since  it  is  primarily  a 
financial  repackaging  and  adjustments  to  the  approved  POM  position.  It  is  not  uncomnx>n  for  project 
office  personnel  to  testify  before  the  OSD  analysts  in  the  BES  reviews.  This  testimony  can  beoMne 
critical  in  the  Program  Budget  Decision  (PBD)  analysis. 

d.  LESSONS  .cARNED:  During  the  OSD  POM  deliberations  and  reviews,  it  is  important  that 
the  project  manager  keep  in  close  contact  with  the  Program  Element  Monitor.  This  is  important  to  help 
resolve  issues  that  may  arise,  and  to  ensure  that  the  PEM  fully  understands  all  the  pertinent  aspects  of 
the  project,  and  can  defend  the  projected  resource  requirements.  Moreover,  the  Project  Office  must 
ensure  that  the  PEM  is  provided  all  documentation  needed  to  support  the  project.  The  need  for 
consistency  in  the  data  provided  cannot  be  over-emphasized. 

e.  BEST  PRACTICES:  After  submission  of  the  POM  package,  the  project  office  should  posture 
itself  to  be  able  to  respond  effectively  to  programmatic  questions,  often  wKhin  a  few  hours,  and  be  able 
to  generate  quantitative  answers  to  the  PEMs  requests  to  develop  and  price  out  program  variations  to 
the  POM  submission.  The  capability  to  generate  quality  'what-if"  information  quickly  (within  a  few  hours) 
is  important,  since  the  PEM  may  be  required  to  make  rnodifications  to  the  Air  Force  POM  request  in 
terms  of  funding  levels,  quantities,  schedules,  or  other  programmatic  aspects.  If  a  project  office  is 
unable  to  provide  the  necessary  information  in  time  to  support  the  decision  makers,  the  project  may  not 
be  supported,  or  might  be  approved  with  insufficient  funding  levels.  Further,  if  the  project  office  doesn't 
provide  the  data  in  a  responsive  manner,  the  PEM  (or  others)  may  be  forced  to  use  whatever  information 
they  have  at  hand  -  whatever  information  we  can  provide  should  be  better  than  what  is  generated  without 
our  ir^s.  Also,  it  is  ncM  unusual  for  project  office  personnel  to  try  to  get  invited  to  the  OSD  reviews. 

f.  TRAPS:  If  this  is  the  first  POM  submission  for  the  project,  the  submission  should  be 
considered  a  "New  Start,"  and  identified  as  such.  There  may  be  additional  documentation  requirements 
and  a  higher  level  of  review  for  these  projects/programs,  since  there  is  not  an  existing  funding  line.  Due 
to  this,  the  project  office  must  be  especially  prepared  to  defend  project  requirements  and  perform 
programmatic  excursions.  As  more  partic^ion  occurs  in  the  review  process,  the  need  for  consistency 
in  the  information  provided  is  essential,  to  limit  confusion  and  obtain  OSD  support. 
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1.  ELEMENT:  A14.  TBS  1.4.01.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Validate  STA(R)  (DIA) 

3.  ELEMENT  OWNER(S):  Defense  Intelligence  Agency  (DIA) 

4.  ELEMENT  STAKEHOLOER(S):  HQ  USAF/IN.  HQ  AFIC.  HQ  AFISA/IN,  HQ  USAF/ICQ. 

HQ  USAF/XOR,  SAF/AQ,  Operating  Commands,  Implementing  Command,  Product  Centers,  Product 
Centers'  Director  Of  Intelligence,  PEO,  and  DAC. 

5.  REQUIREMENT: 

a.  DOD  Directive  5000.1 ,  Defense  Ac^isition,  Part  1 ,  para.B,  2  c,d,  23  Feb  91 .  Specifies  that 
intelligence  reports  wiH  be  part  of  every  acquisition  program. 

b.  DOD  Instnjction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  Part  4, 
Section  A,  paragraphs  2  and  3, 23  Feb  91 .  Policies  and  procedures  for  inteHigence  support  for 
acquisition  programs. 

c.  DOD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  Part  13, 
Section  A,  paragraphs  4,b,(1  )(b)  and  (f),  and  Part  1 1 ,  Section  C,  Atch  1 ,  23  Feb  91 .  Program  Draft  and 
Final  Documentation  Submissions. 

d.  DIA  Regulation  55-3,  Intelligence  Support  for  Defense  Ac^'isition  Programs,  paragraphs  7 
thni  1 0, 30  Mar  92.  Directive  which  describes  how  to  support  acquisition  programs. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  Defense  Intelligence  Agency  (DIA)  is  required  to  validate  the  threat  to  be 
countered  (contained  in  the  Operational  Requirements  Document  (ORD)  and  STAR)  and  prepare  the 
intelligence  report  in  support  of  each  Defense  Acquisition  Board  (DAB)  Milestone  Decision  Review. 

b.  Objective;  To  get  the  STAR  approved  prior  to  Acquisition  Board  Review. 

7.  DESCRIPTION:  At  this  point  in  the  process,  DIA  is  required  to  validate  the  work  of  the  Component 
Intelligence  Senrice  to  provide  a  cross  check  of  the  threat  documentation  prior  to  the  review  process. 

This  activity  should  begin  as  soon  as  the  threat  document  is  ready  and  conclude  prior  to  the  DAB  review. 
DIA  is  required  to  validate  threat  documentation,  threat  data  bases,  and  threat  assessment  procedures 
used  in  artalyses  leading  to  milestone  decisions  and  system  development. 

a.  To  initiate  validation  of  the  STAR,  HQ  USAF/IN  will  forward  threat  documents  to  DIA  under  a 
covering  memorandum  indicating  their  approval  or  disapproval.  In  this  case,  the  threat  document  is  the 
STAR  that  was  prepared  specifically  for  the  appropriate  alternative  concept(s)  selected  for  presentation 
at  MS  I  review.  STARs  prepared  in  support  of  joint  programs  must  have  othw  Componerk  (Army,  Navy, 
etc.)  coordination  prior  to  submission  to  DIA.  Other  DAB  documentation  with  threat  content  will  be 
consistent  with  the  STAR  and  fonvarded  to  DIA  by  the  cognizant  DoD  offices.  DIA  review  and  validation 
will  be  based  upon  the  intended  use  of  the  document  to  support  the  system  acquisition.  DIA  review  will 
stress  appropriateness  of  the  judgments,  consistency  with  existing  intelligence  positions,  and  logic  of 
extrapolations  from  existing  intelligence.  Upon  receipt  and  incorporation  of  DIA  comments,  HQ  USAF/IN 
will  forward  a  letter  to  DIA  certifying  that  the  changes  have  been  made,  or  provide  a  written  reclame  with 
justification.  In  case  you  nin  across  any  documents  you  need  for  your  project  /  study,  check  for  the 
following  statements  to  see  if  they  have  been  reviewed.  Documents  reviewed  and  validated  will  have 
the  following  statement  in  the  preface;  The  Defense  Intelligence  Agency  has  validated  this  document 
for  use  in  analysis  supporting  (Program  name)  Milestone  I  decisions  and  development  activities  taking 
place  during  Phase  1.*  Where  documents  are  validated  but  do  not  support  a  specific  program,  the 
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following  statement  wiN  be  used;  The  Defense  Intelligence  Agency  has  validated  this  document  for  use 
in  support  of  the  systems  acquisition  process  *  Notification  of  nonvalidation  wiN  be  provided  to  HQ 
USAF/IN  as  soon  as  possible. 

b.  A  written  Intelligence  Report  wiU  be  provided  by  OIA  to  the  DAB  Milestone  Decision  Authority 
prior  to  each  Milestone  Decision  Review.  For  Milestone  I,  Concept  Demonstration  Approval,  the 
intelligence  report  will  confirm  the  validity  of  the  data  base  and  documents  used  to  define  the  threat  to  be 
countered  and  projected  threat  that  has  been  developed  for  the  preferred  concept(s)  that  supports  the 
ORD.  There  is  no  need  to  develop  a  STAR  for  every  coricept  that  was  stur^  in  Phase  0.  Only  the 
preferred  concept(s)  should  have  a  STAR  developed  for  H. 

c.  In  addition  to  reviewing  arxf  validating  the  STAR,  a  DIA  Intelligence  Report  will  be  prepared 
by  the  DIA  and  subtrutted  to  the  Under  Secretary  of  Defense  for  A^isition  (USDA),  the  Joint 
Requirements  Oversight  Council  (JROC),  the  Component  Acquisition  Executive  (CAE),  the  Program 
Executive  Officer  (PEO)  and  the  Program  Manager  as  part  of  the  DAB  Conwnittee  and  DAB  read-ahead 
packages.  The  report  is  approved  by  the  Director  of  the  DIA. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  entrance  criteria  for  this  element  is  D56,  Update  Systems  Threat  Assessment 
(Report)  (STA(R)).  The  Product  Center  Director  of  InteHigence  (Dl)  (for  ASC  it  is  ASC/NAIC/TIA) 
normally  prepares  the  STAR,  DIA  validates  the  STAR  for  ACAT I  Projects.  If  the  project  is  not  ACAT  I, 
HQ  USAF/IN  approves  the  STA.  At  the  DAB,  normally  AFISA  briefs  the  STAR. 

b.  Exit;  This  element  exits  to  B22,  Review  Milestone  I  Documents  (Air  Force).  The  threat 
content  in  the  STAR  is  reviewed  for  inclusion  in  the  MS  I  data  package. 

9  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs.  Threat  documents  and  the  STAR  forwarded  by  the  DoD  Component  to  DIA  tor 
validation.  The  STA  is  validated  by  AFISA/INA. 

b.  Outputs;  A  validated  threat  document  and  DIA  Intelligence  Report. 

10.  KEY  REFERENCES: 

a.  AF  InstnKtion  10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,  paragraph  1 .1 .7, 16  Feb  93.  Section  A  covers  the  format  for  writing  an  ORD  or  MNS. 

b.  AFSCR  200-3,  Threat  Assessment  Documentation,  Atch  1.  para.  4  b..  5  April  1985  Describes 
how  to  put  together  a  STAR 

1 1 .  IMPLEMENTATION  TOOLS:  The  threat  and  intelligence  data  bases,  which  consist  of  validated 
STARS,  Threat  Assessment  Reports  (TARs).  Threat  Planning  Documents  (TPDs).  Threat  Environment 
Documents  (TEDs),  approved  Science  and  Technology  ($  &T)  intelligence  reports,  regulations,  standard 
operating  procedures,  and  other  intelligence  data,  such  as  translations  of  for^n  reports,  books,  and 
documents.  The  Product  Center  Dl  should  be  contacted  (or  access  to  these  tools. 

12.  PLANNING  GUIDANCE:  Contributors  to  threat  documentation  need  to  review  the  draft  report  to 
ensure  accurate  use  of  their  data.  The  Product  Center  Dl  is  responsible  for  the  drafting  and  coordination 
review  of  the  STAR.  NAIC,  the  Using  Command,  AFISA,  and  DIA  will  review  draft  assessments  tor 
completeness,  consistency,  currency  and  accuracy.  To  speed  up  the  validation  process,  HQ  AFMC/IN 
and  NAIC  should  review  the  draft  sirrNjItaneously.  When  feasible,  HQ  AFMC/IN  will  give  the  DIA 
comments  from  each  review  level  via  secure  phone  to  minknize  delays  (Ref.  AFSCR  200-3,  Atch  1 , 
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para.  4  b.).  Points  of  contact  for  additional  information  are  HQ  USAF/XORJ.  DSN  225-7107; 
ASC/NAIC/TIA,  DSN  785-4285;  HQ  AFISA/INAA.  DSN  225-7577. 

a.  DURATION:  When  possible,  the  STAR  should  be  prepared  in  time  to  allow  DIA  to  review 
and  coordinate  on  the  STAR  arxf  draft  their  Intelligence  Report.  It  should  be  validated  by  DIA  and 
published  at  least  1  month  before  the  DAB  or  Air  Force  Systems  Acquisition  Review  Courx;it  (AFSARC). 
The  DIA  trrtelligence  Report  provides  DIA's  independent  judgments  and  commerrts  on  the  Component- 
produced  STAR  and  will  be  no  more  than  10  pages  in  length.  The  final  Intelligence  Report  arxj  STAR 
are  due  to  the  DAB  committee  no  later  than  10  working  days  prior  to  the  DAB  Committee  Review. 

b.  CONSTRAINTS: 

(1 )  Limitation  on  the  availability  of  data  flow  and  data  bases. 

(2)  Limitations  on  the  availability  of  project  staff. 

(3)  Restriction  on  time  and  money  needed  to  get  the  job  done. 

(4)  Restrictions  on  the  availability  of  equipment  and  facilities  needed  to  perform  the 

task. 

(5)  Classification  of  data. 

c.  RESOURCES:  Manpower,  personnel,  training,  time,  money,  and  materials  are  needed  to 
accomplish  this  element.  The  SPO  should  have  at  least  one  person  detailed  to  track  this  document  on  a 
part  time  basis. 

d.  LESSONS  LEARNED:  Failure  to  review  and  update  threat  assessment  products  at  key 
program  points  can  allow  development  of  ineffective  or  unneeded  weapon  systems.  It  is  likely  that  a 
poor  STAR  or  a  threat  that  is  not  documented  in  sufficient  detail  to  warrant  a  new  system  will  cause  the 
project  or  study  to  be  terminated.  The  focal  point  for  STAR  issues  and  information  is  the  Product  Center 
Dl  (for  ASC  It  is  ASC/NAIC/TIA). 

e.  BEST  PRACTICES:  Early  and  continued  collaboration  among  the  intelligence,  requirements 
generation,  and  acquisition  management  communities  should  be  maintained  to  ensure  the  timely 
availability  of  validated  threat  information.  The  following  items  should  be  addressed  to  aid  in  the 
development  of  a  first  class  STAR; 

(1 )  Increase  accuracy  arxf  timeliness  of  threat  assessments. 

(2)  Establish  and  maintain  close  cooperation  among  DIA,  USAF/IN,  Product  Center  Dl, 
and  other  Intelligence  activities. 

(3)  Ensure  multifaceted  aspects  of  intelligence  assessments  are  available  to  support  the 
acquisition  process. 

(4)  Improve,  update  and  maintain  current  database. 

(5)  Emphasize  monitoring  of  advanced  technology. 

(6)  Meet  schedule  requirements. 

(7)  Inaease  responsiveness  to  customer. 
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f.  TRAPS:  Failure  to  evaluate  documentation  regularly  wi  resuK  in  assessments  that  are 
neither  current  nor  accurate.  To  avoid  schedule  delays  »  meeting  the  required  milestone,  allow  for  m^ 
delays  during  the  review  process.  Use  of  the  FAX  may  be  helphil.  Watch  for  classification  issues  with 
electronic  transfer.  Make  sure  STA(R)s  are  current  arid  do  not  reflect  ‘Cold  War”  assumptions. 
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t  y  1.  ELEMENT:  A15.  TBS  1.4.02.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  and  Approval  of  Acquisilion  Strategy  Report  (ASR),  Request  for  Proposal 
(RFP),  Source  Selection  Plan  (SSP)  1:^  Milestone  Decision  Authority  (MOA) 

3.  ELEMENT  OWNER(S):  Office  of  the  Secretary  of  Defense  (OSD),  specifically,  the  Under  Secretary 
of  Defense  for  Acquisiton  (USD(A)). 

4.  ELEMENT  STAKEHOLOER(S):  Virtu^  everyone  involved  in  the  decision  making  process  for  a 
major  new  acquisition  is  a  stakeholder  in  this  process:  Project/Program  Managers,  Integrated  Product 
Teams,  Program  Executive  Officers  (PEOs),  Operational  Users,  HO  AF/XO,  and  SAF/AQ. 

5.  REQUIREMENT:  Under  Mr.  Yockey  (USD(A))  in  the  Bush  administration,  this  review  was  being 
handle  on  a  case  by  case  basis.  His  replacement  with  the  Clinton  administration  has  yet  to  set  a  new 
policy.  With  the  release  of  Change  1 ,  (10  March  1993)  to  DoDI  5000.2,  the  procedure  has  been 
expanded  and  institutionalized. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  purpose  for  conducting  this  review  is  to  aUow  the  Milestone  Decision  Authority 
(MDA)  the  opportunity  to  review  the  Acquisition  Strategy  Report  (ASR)  and  the  proposed  request  for 
proposal  (RFP)  as  previewed  by  SAF/AQ  (B1 7)  prior  to  entering  into  tt^  milestone  approval  sequence. 
Subsequent  to  the  MDA,  the  dooimentation  is  returned  to  SAF/AQ  to  incorporate  the  changes  and  then 
approve  the  Acquisition  Plan  (B17). 

b.  Objectives;  The  objective  is  twofold; 

^  1 )  To  allow  the  milestone  decision  authority  the  opportunity  to  say  no  without  going  through 

alt  the  pain  and  effort  of  the  milestone  decision  cycle,  and 

2)  To  allow  the  project  team  to  conduct  the  entire  solicitation  and  source  selection 
processes  while  the  other  members  of  the  project  team  prepare  for  and  execute  the  milestone  decision 
sequence.  The  end  result  of  this  process  is  a  contractor  signed  contract  available  for  the  milestone 
decision  authority  to  review  as  part  of  the  milestone  decision  package.  Since  the  MDA  is  generally  the 
source  selection  authority  on  ACAT  ID  and  selected  DAB  programs  (although  this  is  not  always  the  case 
"  with  the  F-22,  Mr.  Yockey  was  the  MDA  but  Secretary  Rice  was  the  source  Selection  Auth^y),  then 
the  delay  in  the  contract  award  following  the  Milestone  I  decision  is  minimal,  dependent  only  on  the 
Acquisition  Decision  Memorandum  (ADM)  and  the  subsequent  Program  Management  Decision  (PMD). 

7.  DESCRIPTION: 

This  illustrative  example  is  taken  directly  from  DoDI  5000.2,  Section  2.  Note  that  this  example, 
as  a  result  of  the  1 0  March  1993  Change  1 ,  is  now  applicable  to  at  Milestones  I,  II,  and  III.  Part  2 
describes  how  this  process  is  executed  for  the  different  milestones,  Ihe  Milestone  Decision  Authority  will 
approve  the  Acquisition  Strategy  Report  concurrent  with  the  Acquisition  Decision  Memorandum.  The 
formal  solicitation  for  Phase  I,  Demonstration  and  Validation,  shall  be  released  after  the  Milestone  I 
Review  and  program  new  start  review.’ 

The  USD(A)  is  fully  exercising  the  option  afforded  in  DoDI  5000.2,  Part  2;  ’On  an  exception 
basis,  the  Milestone  Decision  Authority  may  require  a  formal  review  meeting  on  the  Acquisition  Strategy 
Report  prior  to  approval.’ 

The  instructions  in  Part  2  of  DODI  5000.2  are  basically  applicable  to  both  Milestones  I  &  II  on 
selected  ACAT  ID  acquisition  programs  (this  activity  is  applicable  to  Milestone  III  decisions  only  if  there 
has  been  a  revision  to  the  Acquisition  Strategy  Report  already  approved  at  Milestone  II). 
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The  question  is;  *How  will  I  know  if  my  project  wW  be  one  of  these  selected  ACAT 10  acquisition 
programs?'  According  to  the  Secretariat  for  this  review,  notification  is  usually  given  in  the  Mtest^  0 
AOM.  This  is  the  method  used  in  the  case  of  the  A/FX  project  (a  recent  Navy  led  joint  fighter 
development  program). 

On  category  1C  projects/programs,  a  formal  review  is  not  automatically  required.  There  is  a 
requirenwnt  to  give  30  days  notification  prior  to  the  release  of  the  RFP,  the  anrKxjncement  of  a  selected 
offeror,  or  the  announcement  of  contract  award.  After  receiving  this  notification  the  USO(A)  wfil  notify 
the  Air  Force  AcquisKion  Executive  as  to  whether  the  USO(A)  intends  to  review  the  RFP  or  contract  prior 
to  release. 

Enroute  to  the  USD(A)  review  there  will  be  several  prebriefs  culminating  with  SAF/AQ. 

Following  the  approval  of  the  Acquisition  Strategy  Report  and  a  favorable  review  of  the  RFP  and  Source 
Selection  plan  by  the  USD(A),  the  entire  package  is  returned  to  SAF/AQ,  who  wiH  then  prov^  final 
approval  of  the  Acquisition  Plan.  An  approved  Acquisition  Plan  is  required  by  Federal  Acquisition 
Regulations  (FARs)  prior  to  the  release  of  a  formal  Request  for  Proposal  (RFP). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  entrance  into  this  process  occurs  when  the  development  community  and  the 
user  community  come  together  on  the  plan  of  attack  for  project/program.  Once  this  is  accomplished,  you 
can  put  together  an  Acquisition  Strategy  Report.  At  this  point  in  the  project  the  majority  of  the  CE&O 
technical  activities  have  been  complete  and  the  focus  has  shifted  to  ’packaging*  the  findings. 

b.  Exit;  The  exit  criteria  have  been  met  when  the  USD(A)  approves  the  Acquisition  Strategy 
and  has  favorably  reviewed  the  Acquisition  Plan. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  The  key  inputs  included  in  the  documentation  package  submitted  by  SAF/AQ  (B1 7) 
are: 


(1)  Acquisition  Strategy  Report  (ASR)  --  Reviewed  and  approved  by  the  Acquisition 
Strategy  Panel  (ASP)  (D61) 

(2)  Request  for  Proposal  (RFP)  (as  required)  -  The  RFP  should  have  already  been 
through  a  Draft  RFP  process  and  be  ready  for  form^  release.  (D64) 

(3)  Acquisition  Plan  -  Developed  with  inputs  from  the  ASP.  the  ASR  and  the  draft  RFP 

(D66). 


(4)Source  Selection  Plan  -  Developed  by  the  RFP  team  (D62). 
b.  Outputs; 

(1)  USD(A)  approved  ASR  -  to  be  used  by  the  Operational  Roundtable  as  a  ’core’ 
document  to  ’harmonize’  the  other  milestone  documentation  and  functional  plans  (D67). 

(2)  The  approved  ASR  allows  SAF/AQ  to  approve  the  Acquisition  Plan  (81 7)  --  which 
will  allow  the  proposal  to  be  put  on  the  street  and  b^in  the  formal  solicitation  process  (D69). 


10.  KEY  REFERENCES: 

a.  DoDI  5000.2,  Change  1,10  March  1993. 
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b.  DoO  5000.2  Manual.  Change  1,10  March  1993. 

c.  AFMC  Pamnhiflt  800-7  Integrated  Acquisition  Strataov  Process.  20  Nov  92 

1 1 .  IMPLEMENTATION  TOOLS:  The  ASC/YX  Integrated  Process  Flowchart  does  an  excellent  job  in 
showing  the  interrelationship  of  the  lASP  activities  with  that  of  the  USD(A)  review. 

12.  PLAI«NNG  GUIDANCE: 

a.  DURATION:  The  actual  SAF/AQ  review.  USO(A)  review  and  SAF/AQ  follow-up  review  are 
only  a  day  each. 

b.  CONSTRAINTS:  TIME  !  Given  the  real  world  constraints  with  the  above  mentioned  duration 
and  timing,  lead-time  for  this  event  is  considerable.  Plan  on  at  least  the  following: 

(1 )  9-11  months  to  form  the  RFP  team,  train  the  team,  and  then  have  then  prepare  an 
RFP  appropriate  for  the  USD(A)'s  review. 

(2)  6-8  weeks  to  form,  notify,  and  conduct  an  Acquisition  Strategy  Panel  (ASP) 

(3)  Allow  2-4  weeks  to  incorporate  ASP  comments  for  SAF/AQ  review 

(4)  2  -4  weeks  to  build  the  Acquisition  Plan. 

(5)  8  weeks  lead-time  to  get  on  the  SAF/AQ's  calendar 

(6)  Allow  2-4  weeks  to  incorporate  SAF/AQ's  comments  in  preparation  for  the  USO(A) 

review 


(7)  8  weeks  lead-time  to  get  on  the  USD(A)'s  calendar 

(8)  Allow  2-4  weeks  to  incorporate  USD(A)'s  comments  in  the  SAF/AQ  follow-up 

review 

True,  many  of  these  activities  can  be  done  concurrently,  but  the  project  team  needs  to  be  looking  ahead. 
A  hypothetical  time  line  on  a  Gantt  chart  is  provided  below: 

c.  RESOURCES:  The  only  resources  required  is  a  knowledgeable  and  highly  polished  briefing 
team,  but  to  prepare  for  this  endeavor  plan  on  a  team  of  15  -  25  people  to  devebp  the  RFP. 

d.  LESSONS  LEARNED:  Come  to  both  of  these  reviews  with  a  complete  set  of  support 
information.  Have  the  back-ups  ready.  Ensure  the  team  has  fully  complied  with  the  guidance  provided 
from  the  Strategic  Roundtable  and  the  ASP. 

e.  BEST  PRACTICES:  This  entire  process  was  designed  basically  to  prevent  a  large  break  in 
a  program  at  Milestone  II  while  they  prepared  the  solicitation  for  the  next  phase.  It  also  serves  a  second 
purpose;  it  allows  the  Milestone  Decision  Authority  (MDA)  the  opportunity  to  have  two  detailed  reviews 
(this  one  and  the  DAB  review)  of  a  major  or  a  politically  sensitive  project/program  prior  to  committing  to 
a  new  start.  The  earlier  the  project  team  engages  with  the  action  officers  at  the  SAF/AQ  and  USD(A) 
levels,  the  better .  The  more  they  know  about  how  and  why  the  team  arrived  at  certain  decisions  the 
fewer  questions  there  will  be  down  the  road.  This  review  process  is  an  excellent  opportunity  to  build  a 
constituency  ~  don't  pass  it  up.  Make  the  SAF/AQ  action  officers  a  part  of  the  project  team  and  the 
decision  making  process. 
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f.  TRAPS:  Failure  to  allow  enough  lead  time.  Looking  at  the  hypothetical  schedule  given  in 
constraints  area,  it  is  apparent  that  tNs  is  a  significant  everrt  and  requires  planning.  Recommend  this 
activity  be  addressed  during  the  development  of  the  Phase  I  plan  and  the  lASP  execution  plan  (D55). 
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1.  ELEMENT:  A16.  TBS  1.4.10.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  Joint  Requirements  Oversight  Council  (JROC)  Requirements  Review 
and  Validation 

3.  ELEMENT  OWNER(S):  Chairman  of  the  JROC 

4.  ELEMENT  STAKEHOLOER(S):  Chairman  of  the  Joint  Chiefs  of  Staff  ,  Vice  Chairman  of  the  Joint 
Chiefs  of  Staff;  Vice  Chief  of  Staff.  United  States  Army;  Vice  Chief  of  Naval  Operations;  Vice  Chief  of 
Staff,  United  States  Air  Force;  Assistant  Commandant.  United  States  Marine  Corps,  Operating  and 
Implementing  Commands,  and  Product  Centers. 

5.  REQUIREMENT:  DoD  Directive  5000.1 ,  ‘Defense  Acquisition,*  23  Feb  91 .  Part  2.  The  Mission 
Need  Statement  for  Major  Defense  Acquisition  programs  will  be  fonwarded  through  established  review 
channels  to  the  JROC.  Part  2  identifies  who  chairs  the  JROC  and  what  ttie  CourKil  function  is. 

6.  PURPOSE/OBJECnVES: 

a.  Purpose:  Validate  the  proposed  key  performance  objectives  and  thresholds  extracted  from  the 
Operational  Requirements  Comment  (ORD)  and  included  in  the  performance  section  of  ACAT  ID 
Acquisition  Program  Baselines  1  APBs)  prior  to  start  of  the  acquisition  process  for  all  Milestone  I 
programs  reviewed  by  the  Defense  Ac^isition  Board  (DAB). 

b.  Objectives'.  Emphasis  is  placed  on  fulfilling  the  needs  arfo  eliminating  deficiencies  by 
accomplishing  the  following: 

(1)  Confirm  that  the  mission  need  is  still  valid. 

(2)  Confirm  that  the  proposed  performance  objectives  and  thresholds  satisfy  the  need,  given  a 
validated  threat  assessment. 

(3)  Provide  recommendations  on  proposed  cost,  performance,  and  schedule  trade-offs  based  on 
affordability,  technological  constraints,  interoperability,  and  overall  program  progress. 

7.  DESCRIPTION: 

a.  The  Chairman  of  the  JROC  (Vice  Chairman  of  the  Joint  Chiefs  of  Staff)  is  the  principal  military 
advisor  to  the  Chairman  of  the  Joint  Chiefs  of  Staff  with  respect  to  military  requirements  and  shall  decide 
all  matters  before  the  Council. 

(1)  The  draft  Acquisition  Program  Baseline  (APB)  will  be  provided  to  the  Secretary  of  the  JROC 
by  the  Executive  Secretary  of  the  DAB  no  later  than  59  calendar  days  prior  to  a  scheduled  DAB  review. 

(2)  The  JROC  will  hold  a  review  with  the  program  sponsor  (operating  command)  of  a  program 
scheduled  for  a  milestone  review  no  later  than  28  calendar  days  prior  to  the  DAB  review.  The  purpose  of 
the  review  is  to  ensure  that  the  performance  objectives  and  thresholds  (extracted  from  the  Operational 
Requirements  Document  (ORD)  and  the  Cost  and  Operational  Effectiveness  Analysis  (COEA)  and  listed 
as  key  parameters  in  the  performance  section  of  the  draft  APB  provide  a  capability  that  will  satisfy  the 
mission  need.  The  program  sponsor  ensures  the  briefing  reviews  the  mission  need,  identifies  (and 
updates,  as  required)  the  related  threat,  and  describes  how  the  proposed  performance  objective  and 
thresholds  will  satisfy  the  mission  need.  The  JROC  provides  its  recommendations  to  the  DAB  in  a 
written  assessment. 
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(3)  The  JROC  will  review  results  of  concept  ex|;^atbn  and  definition  studies  (including  the 
COEA)  and  provide  an  appropriate  recommendation  on  alternatives  to  the  Under  Secretary  of  Defense 
for  Ac^isition  (USD(A))  prior  to  the  Milestone  I  (New  Start)  review.  In  its  review  process,  the  JROC 

ensures  that  military  requirements  are  linked  to  the  national  military  strategy.  Emphasis  is  placed  on  • 

fulfilling  the  needs  and  eliminating  deficiencies  of  the  combatant  commands,  while  ensuring 
interoperability,  reducing  parallel  and  duplicate  development  efforts,  and  promoting  economies  of  scale. 

(4)  The  JROC  may  additionally  charter  and  may  task  study  groups  to  address  operational 
concept  definitions,  joint  potential,  and  join!  requirements  issues. 

» 

b.  The  JROC  is  not  involved  in  ACAT  ll-IV  programs  except  in  instances  where  JROC  assistance  is 
requested  for  the  purpose  of  resolving  Sen/ice  only  issues.  Therefore,  in  instances  for  ACAT  ll-IV,  the 
individual  Service  Chief  or  DoD  component  head,  with  the  implementing  command  Project  Manager's 
assistance,  will  prepare  and  may  validate  their  own  documentation  which  is  required  for  the  particular 
milestone  review.  They  are  not  viewed  as  the  user  in  this  instance  and  this  also  applies  to  the 

Commanders  in  Chief  (CINCs).  However,  the  preferred  course  of  action  is  for  the  CINCs  not  to  write  • 

their  own  Mission  Need  Statement.  The  required  coordinated  documentation  is  provided  via  Memo  to 
the  Milestone  Decision  Authority  (MDA). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  Normally  this  occurs  after  completion  of  the  Air  Force  Systems  Acquisition  Review  • 

Council  (AFSARC)  review  (B24)  and  receipt  of  the  draft  APB  (from  the  Executive  Secretary  of  fhe 

Defense  Acquisition  Board)  not  later  than  59  calendar  days  prior  to  a  scheduled  Defense  A^uisition 
Board  review.  The  JRCX)  will  review  the  documentation  for  the  purpose  of  confirming  that  the  proposed 
performance  objectives  and  thresholds,  which  are  identified  in  the  APB,  provide  an  operational  capability 
that  will  satisfy  the  validated  MNS. 

• 

b.  Exit:  The  assessments,  by  the  JROC.  of  the  proposed  performance  objectives  and  thresholds  for 
the  program  under  review  will  be  submitted  in  a  memo  to  the  USD(A). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  This  consists  of  receipt  of  the  output  of  the  AFSARC  which  is  either  an  Acquisition  • 

Decision  Memorandum  (ADM)  for  non-DAB  programs  or,  for  DAB  programs,  an  updated  Integrated 

Program  Summary  (IPS)  that  goes  to  the  DAB  along  with  other  required  documentation.  A  complete  list 
of  documentation,  which  includes  key  documents  such  as  the  Operational  Requirements  Document 
(ORD)  and  the  Acquisition  Program  Baseline  (APB)  is  identified  in  Conduct  AFSARC  Review  (B24). 

b.  Outputs:  The  product  of  the  JROC  will  be  an  assessment  of  the  proposed  performance  • 

objectives  and  thresholds  for  the  program  under  review.  This  written  assessment  is  the  Council's 
recommendations  that  will  be  submitted  to  the  DAB. 

10.  KEY  REFERENCES: 

a.  DoD  Directive  5000.1, 23  Feb  91,  "Defense  Acquisitjon,"  Part  2.  This  directive  identifies  what  • 

role  the  user's  representative  plays  in  translating  the  broadly  stated  needs  into  operational  performance 

parameters  and  minimum  acceptable  operational  requirements  for  the  proposed  system;  and  identifies 
the  JROC  role  in  Milestone  Reviews. 

b.  DoD  Instruction  5000.2, 23  Feb  91 ,  "Defense  Acquisition  Management  Policies  and  Procedures," 

Part  13,  Section  A,  paragraph  4b(1  )(e)  and  Section  D.  This  directive  contains  the  time  frame  required  by  • 

the  JROC  to  holo  a  review,  with  representatives  of  the  DoD  Component,  prior  to  the  DAB  as  well  as  the 
purpose  and  product  of  the  review.  Section  D  identifies  procedures  for  the  JROC. 
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c.  OoO  Manual  S000.2-M,  23  Feb  91 ,  'Defense  Acquisition  Management  Documentation  and 
Reports,*  Part  2.  This  directive  provides  the  purpose  and  procedures  for  the  MNS.  It  identifies  that  it 
should  be  submitted  to  the  JROC  for  review  and  validation. 

d.  Administrative  Instruction  JROCM-050-92, 6  Jul  92,  (wKh  revised  Briefing  Guide,  JROCM-030-93, 
30  April  1993)  'Joint  Requirements  Oversight  Council.*  This  document  identifies  the  JROC  procedures 
that  are  used  to  process  requirements  for  staffing  of  the  MNS. 

e.  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  Memorandum  of  Policy  (MOP)  No.  77, 17  Sep  92, 
"P..^irements  Generation  System  Policy  and  Procedures.*  This  document  assigns  the  oversight 
responsibility  for  the  requirements  generation  system  to  the  Vice  Chairman  of  the  Joint  Chiefs  of  Staff, 
assisted  by  the  JROC  and  members  of  the  Joint  Staff.  It  defines  the  role  of  the  JROC  Secretary. 

1 1 .  IMPLEMENTATION  TOOLS: 

a.  Administrative  Instruction  JROCM-050-92,  6  Jul  92,  'Joint  Requirements  Oversight  Council.* 

b.  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  Memorandum  of  Policy  (MOP)  No.  77, 1 7  Sep  92, 
"Requirements  Generation  System  Policy  and  Procedures." 

12  PLANNING  GUIDANCE: 

a  DURATION: 

(1)  ACAT I  -  Approximately  60  to  90  days.  (See  CJCS  MOP  77, 17  Sep  92,  Appendix  C,  for 
sequencing.) 

(2)  ACAT  ll-IV  -  Since  the  CINC  may  develop,  validate,  and  approve  their  own  MNS  in 
conjunction  with  any  assistance  that  they  request  from  their  Service  Component,  it  is  customary  for  the 
time  to  be  set  by  the  component.  If  JROC  assistance  is  requested,  it  is  for  the  purpose  of  resolving  lead 
Service  issues  only.  (See  CJCS  MOP  77, 17  Sep  93,  Appendix  C,  for  sequencing.) 

b.  CONSTRAINTS:  The  Project  Manager  will  attend  only  if  requested  by  the  JROC  Chairman  and 
approved  by  the  DoD  Component  Acquisition  Executive. 

c.  RESOURCES:  None  Identified. 

d  LESSONS  LEARNED: 

(1 )  The  user  needs  to  identify  the  key  parameters  from  the  ORD  to  be  included  in  the  APB. 

(2)  The  user  needs  to  set  objectives  and  thresholds  for  the  key  parameters  that  correctly  reflect 
the  defined  program  limits.  The  inability  to  attain  these  objectives  and  thresholds  should  result  in 
program  reassessment  or  termination. 

(3)  The  user  must  ensure  that  the  APB  objectives  and  thresholds  are  consistent  with  the 
objectives  and  thresholds  in  other  program  documents  (i.e.,  ORD)  and  that  they  are  supported  by  the 
COEA. 

e.  BEST  PRACTICES:  Contact  the  Air  Force  JROC  Secretariat  in  AF/XORJ  for  guidance  and 
assistance. 
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f.  TRAPS:  Expect  to  be  challenged  by  Program,  Analysis  and  Evaluation  (PA&E)  if  the  proposed 
key  parameters  and  threshold  values  are  not  supported  by  the  COEA.  Present  rationale  to  JROC  if  this 
is  the  case. 
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1.  ELEMENT:  A17.  TBS  1.4.08.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  Office  of  the  Secretary  of  Defense  (OSD)  Cost  Analysis  Improvement  Group 
(CAIG)  Review 

3.  ELEMENT  OWNER(S):  ASD/PA&E  (OSD) 

4.  ELEMENT  STAKEHOLDER(S):  SAF/FM,  AFCAA.  Operating  Command,  Implementing  Command. 
Product  Cer4er,  PEO,  and  DAC. 

5.  REQUIREMENT:  TKIe  10  United  States  Code  2434  and  DoDI  5000.2,  Defense  Acquisition  Management 
Policies  and  Procedures.  23  Feb  91 ,  Part  13,  Section  C.  establishes  the  basis  for  the  OSD  CAIG  review-  in 
support  of  Defense  Acquisition  Board  (DAB)  reviews. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  To  provide  the  Milestone  Decision  Authority  (MDA)  a  report  on  the  anticipated  life 
cycle  costs  for  the  acquisition  program(s)  being  reviewed. 

b.  Objectives; 

(1 )  Determine  if  the  Program  Office  Estimate  (POE),  the  Component  Cost  Analysis 
(CCA)  and  the  Service  Cost  Position  (SCP)  are  property  prepared  and  documented. 

(2)  Prepare  an  independent  cost  assessment  (Milestone  I)  or  an  independent  estimate 
of  program  costs  (Mileston..e  II  and  III  only). 

7.  DESCRIPTION: 

a.  The  OSD  CAIG  is  one  of  the  key  stops  on  the  way  to  a  Milestone  I  decision.  While  the  review 
described  here  takes  place  after  the  AFSARC  review  (B24)  and  the  OSD  Documentation  Review  'M8), 

it  is  very  important  to  get  them  involved  up  front  when  putting  together  the  plans  for  Phase  0  COTA 
(D23)  and  while  planning  for  the  Milestone  I  review  (A23). 

b.  The  OSD  CAIG  reviews  the  Program  Office  Estimate  (POE),  the  Component  (^st  Analysis 
(CCA)  (formerly  know  as  the  Independent  Cost  Estimate  (ICE)),  and  the  Senrice  Cost  Position  (SCP)  to; 

(1 )  determine  whether  cost  estimating  deficiencies  exist  in  these  estimates  or  their 
documentation  and  if  so,  are  they  significant  enough  that  the  milestone  review  should  be  deferred, 

(2)  validate  the  methodologies  used  to  make  the  estimates. 

(3)  determine  if  additional  cost  studies  are  required,  and 

(4)  understand  the  estimates. 

DODD  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Nov  91 ,  Part  13.  Section 
C,  explains  the  OSD  CAIG  review  procedures. 

(1)  The  CAIG  ICA  and  CAIG  Review  are  only  a  requiremerrt  at  milstone  I  for  ACAT  ID 
programs.  The  CAIG  ICE  and  CAIG  Review  are  required  bv  ^atute  for  both  ACAT  ID  and  1C  programs 
at  Milestones  II  and  III. 
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(2)  The  CARD  must  be  prepared  at  the  planning  meeting  and  a  draft  cost  position  must 
be  provided  with  the  draft  documerrtation. 

c.  The  OSD  CAIQ  uses  POE,  CCA,  SCP,  the  Cost  Analysis  Requirement  Description  (CARD) 
and  other  information  to  develop  its  estimate  of  the  program  life-cycle  costs.  The  results  of  this  analysis 
are  included  in  the  DAB  committee  Integrated  Program  Assessment  and  the  committee  Blue  Book. 

DODD  5000.4,  ’OSD  Cost  Analysis  Improvement  Group  (CAIG),*  provides  more  information  on  the  OSD 
CAIG,  its  membership  and  responsbilities,  the  role  it  plays  in  various  ACAT I  Milestone  reviews,  and 
what  it  will  use  as  the  basis  for  its  estimate. 

d.  The  Project/Program  Manager  attends  the  review  only  if  requested  by  the  CAIG  Chairman 
and  approved  by  the  Assistant  Secretary  of  the  Air  Force  for  Acquisition  (SAF/AQ).  DODD  5000.2,  Part 
13,  Section  C,  provides  guidelines  for  CAIG  briefings.  DOD  5000.4-M,  Chapter  2,  also  provides  guidance 
on  the  presentation  of  cost  results  to  the  OSD  CAIG  and  procedures  for  a  CAIG  presentation. 

e.  The  CAIG  review  normally  takes  place  after  the  Documentation  Review  (AIS)  but  not  later 
than  21  calendar  days  before  the  Defense  A^isition  Board  (DAB)  Committee  Review  (A20). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance: 

(1)  The  Air  Force  Cost  Analysis  Improvement  Group  (AFCAIG)  reviews  (B23)  all  CCAs  and 
associated  POEs,  and  advises  the  Assistant  Secretary  of  the  Air  Force  for  Financial  Management  (SAF/FM)  on 
their  technical  adequacy,  validity,  and  reasonableness.  Ail  CCAs  presented  to  the  OSD  CAIG  must  be  reviewed 
by  the  AFCAIG  in  advance.  The  POE  and  CCA  must  be  approved  by  the  Component  Secretary  before 
submission  to  OSD  (B24). 

(2)  Successful  completion  of  the  planning  meeting  (A23  &  B19)  and  the  approval  of  the  CARD 

(072). 
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(3)  The  OSD  documentation  review  (A18)  should  be  completed  before  the  OSD  CAIG  meets. 

b.  Exit:  POE,  CCA,  and  SCP  pass  OSD  CAIG  test  of  reasonableness.  OSD  CAIG  analysis  included  in 
Committee  Blue  Book 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  CARD(D72). 

(2)  POE(D71), 

(3)  CCA(B21), 

(4)  Service  Cost  Position  (SCP)  (B23). 

b.  Outputs:  OSD  CAIG  estimate  of  program  costs  is  included  in  the  DAB  Committee  Integrated 
Program  Assessment  and  Blue  Book. 

10.  KEY  REFERENCES: 

a.  TITLE  10,  United  States  Code,  Section  2434,  "independent  Cost  Estimates,  Operational  Manpower 
Requirements."  Established  requirement  for  Independent  Cost  Estimates. 
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b.  DoO  Directive  5000.4,  *OSO  Cost  Analysis  Improvefnenl  Group  (CAiQ).*  24  Nov  92.  Explains  OSO 
CAIGs  responsibililies,  reporting  requirements,  and  membership.  Includes  explaruttion  of  requirements  for 
various  acquisition  categories. 

c.  DoO  5000.2-M,  ‘Defense  Acquisition  Man^ment  Documentation  and  Reports,’  Part  1 5,  Feb  91 . 
Provides  guidance  on  developing  and  documenting  POEs  and  ICEs  including  which  program  elements  the 
estimates  must  address. 

d.  DoDi  5000.2,  ‘Defense  Acquisition  Management  Percies  and  Procedures,’  Part  10. 23  Feb  91 . 
Establishes  the  basis  for  the  production  and  review  of  cost  estimates  in  support  of  defense  acquisition  programs. 

e.  DoDI  5000.2,  ‘Defense  Acquisition  Management  Policies  and  Procedures,’  Part  13,  23  Feb  91 . 
Explains  the  purpose  and  timirrg  of  the  OSD  CAIG  review. 

f.  The  AFSC  Cost  Estimating  Handbook,  Chapter  16,  The  Independent  Cost  Analysis  Program.’ 
Provides  background  information  behind  the  establishment  of  the  ICA  program  and  the  role  the  OSD  CAIG  plays 
in  the  Milestone  Review  Process. 

g.  AFR 173-11, ‘Independent  Cost  Analysis  Program,’ 7  Oct  86.  Provides  guidance  on  Air  Force 
implementation  of  the  ICA  program. 

h.  HQ  AFSC/FMC  letter,  ‘Preparation  of  the  Cost  Analysis  Requirements  Description  (CARD)  31  Jan. 

92.  Explains  the  purpose  of  the  CARD  and  provides  guidance  on  what  to  include  in  the  CARD. 

(i)  DOD  5000.4-M,  Cost  Analysis  Guidance  and  Procedures,  Dec  92.  Chapter  2  provides  criteria  and 
procedures  for  the  preparation  and  presentation  of  cost  analyses  to  the  OSD  CAIG. 

11.  IMPLEMENTATION  TOOLS:  None  Identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  A  typical  CAIG  briefing  will  last  2  hours.  DODD  5000.2,  Part  13,  Section  C,  provides  a 
rough  agenda.  Following  is  a  time  line  showing  the  major  events  on  the  way  to  an  OSD  CAIG  review; 

Days  Before 
DAB  Event 

190  SAF/FMC  notifies  the  Implementing  and  Operating  Commands  of  estimate  baseline  requirement 
(CARD)  and  Component  Cost  Analysis  (CCA)  requirements  (i.e.,  COEA,  IPS  summaries,  and 
ICE).  Historically  CCAs/ICEs  have  been  done  by  the  Product  Center  Staffs.  However,  the 
AFCAA  will  do  the  CCA/ICE  for  ACATs  It  &  III  and  should  pick  up  responsibility  for  ACAT I  in  FY 
93andACATIV  inFY94. 

180  DAB  Planning  Meeting  (A23,  Conduct  DAB  Plarming  Meeting)-  The  OSD  CAIG  assesses  the  Air  Force 
progress  in  preparing  key  milestone  documents  such  as  the  COEA  and  cost  estimates.  The 
program  office  CARD  is  reviewed  at  this  time  to  ensure  it  provides  sufficient  program  definition  to 
accomplish  a  CCA  (i.e.,  groundrules  and  assumptions,  systems  description,  technical  descriptors 
and  acquisition  plans).  The  appropriate  SAF/AQ  office  must  endorse  the  CARD  before  it  is 
submitted  to  the  OSD  CAIG  for  discussion  at  the  DAB  planning  meeting.  The  result  of  the  meeting 
should  be  a  fully  coordinated  plan  of  cost  estimating  documentation  required  (scope,  content, 
schedule,  alternative  estimates  required,  etc.). 
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175  CARD  presented  to  DAB  and  POE  documentation  (Progwn  Executive  Officer  (PEOyOesignated 
Acquisition  Commander  (OAC)  approved)  delivered  to  CCA  team  and  SAF/FMCCC 

1 65  Draft  CCA  plan  to  SAF/FMCCC. 

160  SAF/FMCCC  and  CCA  te«n  review  CCA  plan. 

129  Mid-term  review. 

1 04  Final  POE  documentatiori  to  CCA  team. 

88  SAF/FMCCC  leads  reconciliation  of  CCA  to  POE  at  AFMC. 

74  CCA  draft  documentation  to  SAF/FMCCC. 

71  SAF/FMC  technical  director's  "shirt  sleeve*  review  of  POE  and  CCA. 

66  AF  CAIG  meeting.  The  findings  of  the  "shirt  sleeve*  review  are  discussed  and  the  Air  Force  Cost 
Position  is  developed. 

63  AF  CAIG  reports  findings  to  SAF/FM,  includes  recommended  Air  Force  Cost  Position. 

60  AFSARC  briefed  (624,  CofXluct  AFSARC  Review). 

59  Draft  documentation  of  POE  and  CCA  to  OSD  along  with  Final  CARD  as  part  of  Draft  Documentation 
Package. 

44  OSD  Draft  Documentation  Review  (A18,  Review  MS  I  documents). 

35  OSD  CAIG  meeting.  The  purposes  of  the  meeting  are  to  review  independently  the  POE  and  CCA 

(ICE,  COEA,  and  parts  of  IPS  that  discuss  cost/affordabilily);  to  validate  the  methodology  used  to 
make  the  cost  estimates  provided;  to  determine  whether  additional  analysis,  which  the  CAIG  may 
undertake  itself,  is  required;  and  to  be  given  an  explanation  of  the  DoD  Component  cost  position. 

The  program  Manager  may  attend  the  review  only  if  requested  by  the  Cost  Analysis  Improvement 
Group  Chair  and  approved  by  the  DoD  Component  Ao^isition  ^ecutive. 

The  COEA  is  briefed  by  the  Using  Command  (C29,  Brief  COEA  Results  to  OSD(PA&E)). 

The  product  of  the  review  will  be  a  CAIG  independent  cost  position  for  the  program  under  review. 
This  cost  position  will  be  presented  to  the  DAB  Committee  and  included  as  part  of  the  Committee 
Report. 

24  Rnal  Documentation  to  DAB  Executive  Secretary  (A19,  Submit  Rnal  MS  I  Documents  Due).  OSD 
CAIG  assessment  is  included  in  the  Commiltee  Blue  Book. 

14  Systems  Committee  Review  (A20,  Conduct  Committtee  Review) 

0  DAB  (A22,  Conduct  DAB  MS  I  Review). 

b.  CONSTRAMTS:  The  estimating  methods  and  approaches  and  data  availability  are  typically  very 
limited  at  Milestone  I. 
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c.  RESOURCES:  Dependent  on  program  complexity  and  issues.  Formal  brief^  to  CAIGs  may  be 
preceded  by  one  or  two  working  level  reviews,  up  to  a  day  tor^  each. 

d.  LESSONS  LEARNED:  CAIG  reviews  are  critical  milestones  in  the  DAB  process  The  program 
manager  should  attempt  to  get  invited  and  adjust  his  schedule  to  attend  CAIG  reviews  when  invited. 

e.  BEST  PRACTICES:  When  DAB  is  scheduled,  the  p>rogram  office.  AFCAA,  AFCAIG,  and  OSD  CAIG 
representatives  should  meet  as  soon  as  possible  to  ensure  that  the  estimates  to  be  presented  to  the  CAIGs  win 
satisfy  requirements  and  have  consistent  grourxfrules  and  assumptions,  scope,  etc. 

f.  TRAPS:  The  COEA/POE/CCA  may  be  revised  up  to  the  last  minute  prior  to  the  CAIG 
reviews.  It  is  important  that  the  analysis  chief  keep  all  affected  teams  apprised  of  changes  or  problems 
and  that  comprehensive  explanations  of  estimate  differertces  be  provided  to  the  CAIGs.  The  POE,  CCA 
and  SCP  estimates  must  be  corrsistent  with  the  estimates  in  the  Cost  and  Operatkxutl  Effectiveness 
Analyses  and  other  program  documentation. 
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1.  ELEMENT:  A18,  TBS  1.4.09.1  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  Milestone  Documentaikn  (D^ 

3.  ELEMENT  OWNER(S):  OSD/AP&PI/ASM 

4.  ELEMENT  STAKEHOLDER(S):  SAF/AQXA,  Oporating  Command,  Implemeating  Command,  Product 
Center,  reO,  DAC,  and  Projea  Manager 

5.  REQUIREMENT:  DoDlSOOO.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb  91,  Part 
13,  Sections  A  and  B.  Describes  the  requirements,  time  frame,  and  attendees  for  the  Documnitation  Review. 

6.  PURPOSE/(»JECTIVES: 

a.  Purpose:  The  OSD  documentation  review  serves  as  the  single  OSD  meeting  for  identifying  and 
reviewing  major  questions  raised  by  the  draft  documentation,  including  the  adequacy  of  the  documentation,  and 
any  new  developments  since  the  planning  meeting  in  preparation  f»  the  Defense  Acquisition  Board  (DAB)  fw 
Acquisition  Category  (ACAT)  I  acquisitions.  (Detailed  information  regarding  the  entire  DAB  review  process  and 
time  frames  can  be  found  in  DoDI  5000.2,  Part  13,  Section  A.) 

b.  Objectives:  To  ensure  that  issues  raised  by  the  draft  documentation  are  addressed  prior  to  submission 
of  the  final  documents  to  the  DAB  Executive  Secretary. 

7.  DESCRIPTION: 

a.  Prior  to  the  OSD  Documentation  Review,  the  draft  documents  will  have  been  submitted  and  the  results 
documented  in  the  Committee  Memo  (A23).  The  Cost  Analysis  Requirements  Document  (CARD)  wiU  have  been 
reviewed  and  forwarded  for  the  Component  Cost  Analysis  effcxt  (B21).  In  addition,  a  list  of  the  milestone 
documents  required  fOT  the  Milestone  Decision  Authority  (MDA)  will  have  been  forwarded  from  OSD  (A23)  to  the 
Project  Manager  along  with  any  issues  pertaining  to  those  documents  (D68). 

b.  The  Documentation  Review  is  held  ^rproximately  4  months  after  the  DAB  Planning  Meeting  (A23) 
and  no  later  than  30  days  prior  to  the  Committee  Review,  is  chaired  by  the  cognizant  DAB  Committee  rhair  (or  a 
rqtresentadve),  and  includes  representatives  of  the  Committee  principals  and  of  the  DoD  Cranponent  (see  A20  for 
a  list  of  members).  The  DAB  is  supported  by  three  committees  chstered  by  the  USD(A): 

(1)  Strategic  Systems  Committee  (SSQ 

(2)  Conventional  Systems  Committee  (CSQ 

(3)  Command,  Control,  Communications,  and  Intelligence  Systems  Committee  (C3SC) 

c.  The  Project  Manager  begins  the  meeting  with  a  summary  briefing  covering  program  technical  content 
and  risks,  cost-eftecdveness,  threat,  acquisition  strategy,  supportability  and  producibility,  test  plans  and  results,  a 
status  update  since  the  DAB  Manning  Meeting,  and  a  documentation  status  chart  (A23).  The  Project  Manager 
should  answer  the  concerns  and  issues  from  the  planning  meeting  and  from  OSD  review  of  draft  (inrnmMitarinn 
through  his/her  briefing. 

d.  After  completing  the  review,  OSD  documents  the  results  and  major  issues  raised  during  the 
documentation  review  via  the  updated  Majw  Issues  Guidance  Memmandum.  The  memmandum  is  submitted  to 
the  Air  Force  Acquisition  Executive  (AF^  within  5  calendar  days  from  the  Documentation  Review  and  will  be 
coordinated  with  the  DAB  principals.  This  memorandum  will  identify  major  questions  not  answered  at  the 
Documentation  Review  and  any  major  deficiencies  and  issues  regarding  the  draft  milestone  documentation.  The 
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manafanduin  may  also  delete  issues  from  the  milestone  documentation  and  the  Project  Mmiagm's  briefing  for  the 
Committee  Review  if  it  was  agreed  that  the  issue  had  been  resolved  at  the  Documentation  Review.  The  frnal 
documents,  adjusted  to  address  issues  identified  at  the  Documentation  Review,  must  be  submitted  to  the  DAB 
Executive  Secretary  not  later  than  10  days  prior  to  the  scheduled  DAB  Committee  Review  (A19). 

e.  A  DAB  date  will  not  be  finalized  on  the  DAB  Executive  Secretary's  calendar  until  the  Documentation 
Review  is  successfully  completed. 

8.  ENTRANCE/EXrrCRlTERU: 

a.  Entrance:  Thisactivity  begins  upon  receipt  of  the  Service  draft  documentation  by  the  DAB  Executive 
Secretary  at  least  45  days  prior  to  the  planned  DAB  Committee  meeting. 

b.  Exit:  The  results  of  the  Documentation  Review  meeting  are  documented  in  the  updated  Major  Issues 
Guidance  Memmandiun.  which  is  to  be  prepared  within  5  days  after  the  review. 

9.  KEY  INPUTS  AND  OUTPUT: 

a.  Inputs:  The  following  documents  are  to  be  submitted  for  DAB  reviews. 
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ACATl 

Operational  Requirements  Document  (ORD)  (B15) 

System  Threat  Assessment  Repot  (STAR)  (A14) 

DIA  Intelligence  Repot 
JROC  Assessment 

Integrated  Program  Summary  (IPS)  (D68) 

Integrated  Program  Assessment  (IPA) 

Program  Life  Cycle  Cost  Estimate  (PLCCE)  (D71) 

•Acquisition  Program  Baseline  (APB)  D51) 

•Test  &  Evaluation  Master  Plan  (TEl^)  (D68) 

Component  Cost  Analysis  (CCA)  (A17) 

•CCARqtot 

Cost  &  Operational  Effectiveness  Analysis  (COEA)  (B15) 

Draft  Acquisition  Decision  Memorandum  (ADM) 

*Required  by  Congress 

b.  Output:  The  product  of  the  documentation  review  is  a  Committee  Memorandum  to  the  Air  Force 
Acquisition  Executive  (AFAE)  from  the  Committee  Chair. 

10.  KEY  REFERENCES: 

a.  Air  Fmce  Acquisition  Model  (AFAM) 

b.  PEM/Acdon  Officer  Handbook.  Apr  92.  Paragraph  B.4  and  subs.  Describes  the  AFSARC/DAB 

process. 

n.  IMPLEMENTATION  TOOLS;  None  identified. 
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12.  PLANNING  GUIDANCE: 

a.  DURATKM:  Prepanuion  for  the  briefing  can  lake  2  to  3  weeks,  with  several  people  creating  chans 
and  two  dedicated  computer  graphics  specialists  making  viewgraphs. 

b.  CWSTRAINTS: 

(1)  Inadequate  preparation  of  documentation 

(2)  Not  all  documents  submitted  on  titne 

c.  RESOURCES:  The  resources  should  iiKlude  a  conference  room  of  appn^iriaie  size  to  accommodtue 
the  number  of  attendees  for  the  Documentation  Review,  an  operating  vu>gnq)h  marine  and  a  back-up,  an 
individual  to  flip  the  charts  as  the  briefer  presents  his/her  charts,  and  a  secretary  taking  notes  to  ensure  that  all 
comments,  questions,  changes,  etc.,  are  adequately  and  clearly  documented  for  the  resultant  memo  that  will  be 
issued  upon  completion  of  the  review. 

d.  LESSONS  LEARNED: 

(1)  At  the  earliest  possible  date,  ensure  with  the  reviewing  agency  that  there  is  an  agreement  as 
to  what  documentation  is  required. 

(2)  Be  ]»epared  to  assist  in  the  development  of,  guide  the  preparation  of,  research  the 
requirements  for,  and  review  of  all  documentation  to  the  DAB  to  ensure  accurate  and  timely  com;;^etion. 

(3)  Close  liaison  with  the  Pentagon  action  officers  in  the  last  few  days  befcve  the  documentation 
review  can  produce  significant  results  to  the  Project  Manager.  Preliminary  comments  from  the  committee  staff 
will  be  forwarded  the  Air  Force  action  officers  as  the  staff  {nepaies  to  the  meeting.  The  Project  Manager's 
briding  can  be  tailored  at  the  last  minute  to  address  any  known  concerns.  Again,  work  closely  with  the  action 
officer  who  prqjares  the  Major  Issues  Guidance  Memorandum,  to  make  sure  it  correctly  documents  closed  issues 
and  focuses  in  on  a  narrower  scope  for  the  committee  and  DAB  briefing. 

e.  BEST  PRACTICES: 

(1)  To  ensure  that  all  documentation  is  propnly  prepared  in  accordance  with  OSD 
guidance^Mocedures  while  meeting  the  documentation  schedule,  ii^viduals  within  the  SPO  should  be  assigned  as 
Offices  of  Primary  Responsibility  (OPRs)  for  DAB  documents.  Ultimately,  these  individuals  are  leqxMisible  for  the 
success  or  failure  of  the  document  even  if  they  are  not  the  author.  The  OPR  should  identify  and  resolve  issues  that 
could  impact  the  document  completion  timeline. 

(2)  It  would  be  beneficial  to  the  project  to  identify  individuals  outside  the  project  office  to  help 
advise  and  cotvdinate  on  milestone  DAB  issues/dwumentation.  This  relationship  should  prove  beneficial  in 
obtaining  a  quick  turn-around  on  DAB  documents  requiring  OSD-level  signatures,  clarifying  OSD  and  Pentagon 
issues/direction,  and  providing  information  to  the  project  office. 

(3)  Have  the  AF  PEO  staff  obtain  recent  examples  of  Documentation  Review  briefings  and  the 
questions  of  the  various  staff  members.  With  good  "inter  and  a  little  "crystal  ball"  speculation,  a  single  added 
chart  to  the  briefing  may  head  off  a  lengthy  discussion 

f.  TRAPS:  If  the  draft  documents  are  not  received  45  days  before  the  Committee  review,  or  if  the  DAB 
members  are  not  available  on  the  scheduled  date  for  the  DAB,  then  the  DAB  review  will  be  postponed  on  a  (by- 
to-day  basis.  It  is  imperative  that  the  Project  Manager  have  his/her  pecqile  begin  working  on  the  draft  dcKuments 
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well  in  advance  of  the  scheduled  DAB  review  to  ensure  that  they  meet  the  schedule  and  avoid  any  sh^  in  the 
overall  program  achethile. 
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1.  ELEMENT:  A19.  TBS  1 .4.09.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Submit  Final  Milestone  I  Documents  (Air  Force) 

3.  ELEMENT  OWNERiS):  OSO/AP&PI/ASM 

4.  ELEMENT  STAKEHOLOER(S):  SAF/AQXA,  Operating  Command.  Implementing  Command,  and 
Product  Center . 

5.  REQUIREMENT:  OoDI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 ,  Part  13,  Sections  A  and  B.  Describes  the  requirements  and  time  frame  for  final  documentation 
submittal  for  the  Defense  Acquisition  Board  (DAB). 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  event  is  to  ensure  that  the  final  documentation  required  by  the 
DAB  incorporates  any  changes  that  resulted  from  Service  level  review  (e.g.,  AFSARC)  and  addresses 
issues  raised  during  the  Documentation  Review  (A18).  (DetaHed  information  regarding  the  entire  DAB 
review  process  and  ti.ne  frames  can  be  fourfo  in  DoDI  5000.2,  Part  13,  Sections  A  and  B.) 

b.  Objectives:  The  final  documents  are  required  by  the  DAB  Committee  members  in  order  to 
establish  the  ^rvice  position. 

7.  DESCRIPTION:  The  final  documents,  adjusted  to  the  Service  position  and  addressing  issues 
identified  at  the  Documentation  Review  (A18),  as  documented  in  the  Major  Issues  Guidance 
Memorandum,  must  be  submitted  under  the  signature  ot  the  Air  Force  Acquisition  Executive  (AFAE)  to 
the  DAB  Executive  Secretary  not  later  than  1 0  days  prior  to  the  scheduled  DAB  Committee  Review 
(A20).  The  Office  of  the  Secretary  of  Defense  (OSD)  Cost  Analysis  Improvement  Group  (CAIG) 
Assessment  (A17)  is  included  in  the  Committee  Blue  Book  (A20).  The  Service  final  documents  are  the 
basis  for  the  OSD  staff  independent  assessment  of  the  program,  which  is  reflected  in  the  Integrated 
Program  Assessment  (IPA)  (A21). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  This  activity  begins  upon  completion  of  the  Service  level  review  and  release  of 
the  updated  Major  Issues  Guidance  Memorandum  (A18). 

b.  Exit:  Successful  completion  of  the  DAB  Committee  Review  and  issuance  of  the  Committee 
Report  (A20). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  Major  Issues  Guidance  Memorandum  which  addresses  any  major  questions  left 
unanswered  from  the  Documentation  Review  and  identifies  major  deficiencies  and  issues  regarding  the 
documentation.  This  information  will  be  used  by  the  Project  Manager  to  update  the  documents. 

b.  Outputs:  The  following  documents  are  submitted,  as  required,  for  the  DAB: 
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Operatiortal  Requirements  Document  (ORD)  (B15) 
System  Threat  Assessment  Report  (STAR)  (A14) 
DIA  Intelligence  Report 
JROC  Assessment 

Integrated  Program  Summary  (IPS)  (D68) 
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Integrated  Program  Assessment  (I PA) 

Program  Life  Cycle  Cost  Estimate  (PLCCE)  (D71 ) 

’Acquisition  Program  Baseline  (APB)  D51 ) 

’Test  &  Evaluation  Master  Plan  (TEMP)  (D68) 

’Component  Cost  Analysis  (CCA)  (A1 7) 

CCA  Report 

Cost  &  Operational  Effectiveness  Analysis  (COEA)  (B15) 

Draft  Acquisition  Decision  Memorandum  (ADM) 

’Required  by  Congress 

10.  KEY  REFERENCES: 

a.  Air  Force  Acquisition  Model  (AFAM) 

b.  PEM/Action  Officer  Handbook,  Apr  92,  Paragraph  B.4  and  subs.  Describes  the 
AFSARC/DAB  process. 

11.  IMPLEMENTATION  TOOLS:  None  identified 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Updating  the  draft  documents  based  on  the  Service  review  and  determining  the 
disposition  of  the  comments  from  the  Documentation  Review  should  take  approximately  2  weeks  (per 
DoDI  5000.2,  Part  13,  Section  B,  Attachment  1,  Page  3-B-1-1).  If  the  document  requires  approval  or 
validation  by  an  external  agency,  the  turnaround  time  could  take  approximately  2  to  4  weeks. 

b.  CONSTRAINTS: 

(1 )  Inadequate  preparation  of  documentation. 

(2)  Not  all  documents  submitted  on  time. 

c.  RESOURCES:  The  entire  acquisition  team  should  stand  ready  to  turn  around  a  possibly 
massive  amount  of  changes  in  a  relatively  short  period  of  time. 

d.  LESSONS  LEARNED:  When  updating  the  draft  documents,  it  is  very  important  that 
someone  check  to  ensure  that  ail  comments/questions  from  the  Service  review  and  from  the 
Documentation  Review  have  been  addressed  and  incorporated,  if  warranted.  If  this  is  not  done,  there 
could  be  schedule  slippages  if  the  final  documents  have  to  be  returned  because  all  the  comments 
weren't  addressed. 

e.  BEST  PRACTICES:  The  more  time  taken  initially  with  the  draft  documents  to  ensure  they 
are  completed  properly,  consistent  with  each  other,  arx)  coordinated  with  the  appropriate  people  could 
alleviate  massive  changes  during  the  Documentation  Review. 

f.  TRAPS: 

(1 )  Disagreement  between  the  Service  and  the  OSD  staffs  regarding  the  need  for 
changes  identifi^  at  the  Documentation  Review. 

(2)  Significant  changes  from  the  draft  documentation  required  by  the  Service  review. 


D-68 


1.  ELEMENT:  A20.  TBS  1 .4.9.3  (IFC  Rev.  93-3) 

2.  ELEMENT  TITLE:  Conduct  Committee  Review  (OSO) 


3.  ELEMENT  OWNER(S):  USO(A),  Strategic  Systems  Committee  (SSC),  Conventional  Systems 
Committee  (CSC),  and  Command.  Control,  Communications,  and  Intelligence  Systems  Committee 
(C3ISC) 

4.  ELEMENT  STAKEHOLDER(S):  OSD;  Dir.  API.  DepDir  ASM.D.TS;  D,S&SS;  ASD(C3I).  DASD(C3). 
DAB.  CSC,  SSC,  C3ISC 

DOD  COMPONENT;  Dept  of  Army;  ASA(RDA).  SARD-ZBA,  Dept  of  Navy;  ASN(RDA),  Dir,  RE,  and 
Dept  of  Air  Force.  SAF/AQ,  SAF/AQX 

5.  REQUIREMENT:  DODI  5000.2,  Defense  Acquisition  Management  Polkaes  and  Procedures, 

23  Feb  91 ,  Part  13,  Section  B.  Outlines  the  Committee's  role  in  the  acquisition  process. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  Support  the  Defense  Acquisition  Board  (DAB)  decision  process. 

b.  Objectives;  To  accomplish  the  following  in  support  of  the  DAB  decision  process; 

(1 )  Verify  that  exit  criteria  and  the  minimum  rec^ired  accomplishments  of  the  phase  preceding  the 
milestone  have  been  completed. 

(2)  Review  all  issues  and  provide  an  independent  assessment  of  the  program  which,  together  with 
the  Component's  Integrated  Program  Summary  (IPS)  is  the  basis  for  the  DAB  review. 

(3)  Make  recomntendations  on  cost-schedule-performance  trade-offs  proposed  by  the  Project 
Manager  for  decision  by  the  Under  Secretary  of  Defense  for  AcquisKion  USD(A).  (Ref;  DODI  50(X).2,  p. 
13-A-4,  para.  3.c.) 

(4)  Provide  a  'Read-Aheacf  (a  notebook  of  pertinent  information)  to  all  DAB  principals  and 
recommend  issues  to  DAB. 
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7.  DESCRIPTION:  The  Committee  Review  is  one  of  several  activities  as  a  part  of  the  review  and 
approval  of  a  project  to  allow  the  Milestone  Decision  Authority  decide  whether  or  not  a  project  should 
proceed  into  Phase  I,  Demonstration  and  Validation,  of  the  acquisition  process.  At  this  point  in  the 
acquisition  process  the  preferred  altematives  documented  in  the  Cost  and  Operational  Effectiveness 
(COEA)  have  been  briefed  to  OASD(PA&E)  (Block  C29)  and  the  final  Milestone  I  decision  documents 
have  been  submitted  to  OSD  not  later  than  10  davs  prior  to  the  scheduled  committee  review  (Block  A19). 


The  DAB  is  supported  by  three  committees  chartered  by  the  USO(A); 

a.  Strategic  Systems  Committee  (SSC) 

b.  Conventional  Systems  Committee  (CSC),  and 

c.  Command,  Control,  Communications,  arid  Intelligence  Systems  Committee  (C3ISC)  (Ref; 
DODI  5000.2,  p.  13-A-2,  para.  2.b) 

Committees  are  composed  of  representation  from  each  of  the  DAB  principals  and  other  members  as 
determined  by  the  Committee  Chair.  (See  Block  A22.  Conduct  DAB  Milestone  I  Review,  for  a  list  of  the 
DAB  principals.  As  approved  by  the  USD(A),  the  Committees  can  convene  periodically  for  special 
reviews  apart  from  the  DAB  Milestone  Review  process.  The  Committee  meeting  announcements  will 
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identify  those  Committee  members  requested  to  attend;  however,  participation  by  other  members  will  be 
welcomed.  A  master  planning  calendar  prepared  by  the  Committee  staff  specialist  documents  the 
scheduled  Committee  reviews. 

As  part  of  the  DAB  milestone  review  process,  the  cognizant  Committee  Chair  will  convene  a  meeting 
to  review  the  status  of  a  program  at  least  1 4  calendar  days  prior  to  the  scheduled  DAB  Milestone 
Review,  unless  a  shorter  period  of  time  is  specifically  authorized  by  the  USD(A).  (Ref;  DODI  5000.2,  p. 
13-A-11,  para.  4.b.(g).)  The  purpose  and  scope  of  committee  reviews  can  vary.  The  exact  times 
associated  with  each  presentation  are  established  by  the  Committee  Staff  Director  (Ref:  DODI  5000.2,  p. 
13-B-5.  para.  3b). 

In  preparation  for  the  Committee  review  (not  less  than  10  days  prior  to  the  Committee  review)  final 
documentation  is  forwarded  by  a  cover  memorandum  signed  by  the  DOD  Component  Acquisition 
Executive  to  the  committee  staff  specialist  who  will  distribute  final  documentation  to  appropriate 
Committee  Members.  The  Committee  Executive  Secretary  will  provide  a  Read-Ahead  (Blue  Book)  to  all 
committee  members  at  least  2  working  days  in  advance  of  the  Committee  Review  identifying  the  issues 
to  be  discussed  at  the  review.  (Ref:  DODI  5000.2,  p.  13-A-1 1 ,  para.  4.b.(g)2).  The  Committee  Blue 
Book  includes  inputs  from  the  DOD  Component  and  OSD  offices  which  will  assist  Committee  principals 
to  prepare  for  their  meeting.  The  Blue  Book  will  address  the  following  topics  for  Milestone  1  decision: 


Acquisition  Program  Baseline 
DOD(C)  Financial  Status  Assessment 
DIA  Intelligence  Report 
PA&E  Affordability  Assessment 
PA&E  COEA  Assessment 
PA&E  CAIG  Assessment 
JROC  Assessment  (if  available) 

DT&E  Assessment 
OT&E  Assessment 

DUSD  (IP)  Cooperative  Opportunity  Assessment 
FM&P  HSI  Assessment 

P&L  Producibility  and  Industrial  Base  Assessment 
P&L  Supportability  Assessment 
P&L  Environmental  Assessment 

Finally,  no  later  than  1  working  day  prior  to  the  Committee  Review  the  Committee  Staff  Specialist  and 
Director  will  pre-brief  the  Committee  Chair  on  any  unresolved  documentation  issues,  summarize  areas  of 
concern  from  initial  staff  functional  assessments,  and  identify  cost-schedule-perfomriance  tradeoffs  and 
proposed  exit  criteria.  The  Committee  Staff  Specialist  will  bring  the  meeting  to  order,  state  its  purpose, 
and  set  the  context  for  milestone  decision  (nominally  10  minutes).  The  Project  Manager  will  then  be 
responsfele  for  the  component  presentation  (approximately  60  minutes).  During  this  presentation  the 
Project  Manager  and  staff  at  each  review  level  will  provide  a  report  on  the  elements  of  the  model  agenda 
for  reviewing  a  program  at  a  milestone  (Ref;  DODI  5000.2,  p.  11-C-2,  para.  3.a  &  3.b).  During  the 
Committee  Review,  the  Project  Manager  will  brief  the  Committee  on  the  areas  addressed  in  the  IPS  and 
on  proposed  cost-schedule-performance  trade-offs.  The  Committee  members  will  then  present  an 
assessment  of  the  program  in  their  functional  areas,  based  on  a  review  of  the  documentation,  and 
focusing  on  risk,  risk  management,  affordability,  and  proposed  trade-offs.  (Ref:  DODI  5000.2,  p.  13-A- 
12,  para.  4.b.(g)3).  The  presentation  will  focus  on  the  following  (it  will  not  dwell  on  the  criticality  of  the 
need,  operational  concede,  doctrine  or  tactics,  detailed  technical  descriptions,  or  other  information  not 
relevant  to  the  decision  milestone): 

Decision  requested 
Program  execution  status 
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Threat  highli^ts  and  existing  system  shortfalls 

AMematives  assessed  and  results 

Most  promising  alternative  and  rationale 

Acquisition  strategy 

Cost  drivers  and  major  trade-offs 

Risk  assessment  and  plans  to  reduce  risk 

Affordability  of  selected  alternative 

Recommendations 

Key  issues 

Issue  resolution  for  cost-schedule-performance  trades 

The  Committee  Staff  Director  will  then  present  the  OSD  reports.  The  Director  will  review  the  primary 
considerations  necessary  to  make  a  recommendation.  The  Director  will  discuss  issues  in  these  areas 
and  summarize  the  initial  functional  offices  and  their  recommendations.  Proposed  exit  criteria,  tradeoffs, 
and  risk  management  will  also  be  discussed  by  the  Director  (60  minutes). 

The  review  will  focus  on  five  questions  which  will  be  pertinent  to  the  DAB  granting  approval  to 
proceed  into  the  next  acquisition  phase 

1 .  Where  are  we  (versus  where  should  we  be)? 

2.  Where  are  we  going  (and  how  will  we  get  there)? 

3.  What  risk  exists  (and  how  will  we  manage  those  risks)? 

4.  Is  what  we  plan  to  do  affordable? 

5.  Is  the  requirement  being  met? 

8.  ENTRANCE/EXIT  CRITERIA: 

•  a.  Entrance;  Preparation  for  the  Committee  Review  cannot  begin  until: 

(1)  Draft  documents  are  submitted. 

(2)  Document  review  is  conducted. 

(3)  CAIG  and  JROC  reviews  are  held. 

(4)  Final  documents  are  submitted. 

(5)  The  required  DOD  assessments  are  available  as  follows:  (Block  At  6,  Conduct  JROC 
Requirements  Review  and  Validation,  Block  At  7,  Conduct  OSD  CAIG  Review,  Block  At 8,  Review 
Milestone  Docs  (DoD),  and  Block  C29,  Brief  COEA  I  Results  to  OASD  (PA&E) 

DOD(C)  Rnancial  Status  Assessment 
DIA  Intelligence  Report 
PA&E  Affordability  Assessment 
PA&E  COEA  Assessment 
PA&E  CAIG  Assessment 
JROC  Assessment  Ref 
DT&E  Assessment 
OT&E  Assessment 

DUSD  (IP)  Cooperative  Opportunity  Assessment 
FM&P  HSI  Assessment 

P&L  ProducibilHy  and  industrial  Base  Assessment 
P&L  Supportability  Assessment 
P&L  Environmental  Assessment 
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b.  Exit;  This  element  ends  when  sufficient  infonnation  is  available  to  complete  an  independent 
assessment  which  will  be  documented  in  a  forwarding  memorandum  and  an  Integrated  Program 
Assessment  (IPA)  (Ref:  DODI  5000.2.  p.  1 1 -C-2.  para.  3).  (Ref:  Block  A21 .  Write  IPA  (OSD).) 

9.  KEY  IMHJTS  AND  OUTPUTS: 

Inputs:  Milestone  /  documentation  and  AFAE  signed  cover  memorandum  (SubnA  Final  MS  /  Docs 
(Air  ^rce).  A19) 

Output:  IPA  and  Committee  Memorandum  for  DAB  review  (A21 ) 

10.  KEY  REFERENCES: 

DODI  5000.2,  Defense  Acquisition  Management  Policies  arxf  Procedures,  23  Feb  91 ,  Chapter  13. 
Outlines  the  Committee  role  in  the  acquisition  process. 

11.  IMPLEMENTATION  TOOLS:  None  known. 

12.  PLANNING  GUIDANCE:  Individuals  involved  in  the  committee  review  need  to  become  familiar  with 
the  activities  that  must  occur  prior  to  and  following  the  actual  committee  review.  Familiarization  needs  to 
occur  at  least  166  days  prior  to  a  scheduled  committee  review  because  it  is  at  this  point  that  the  planning 
meeting  is  held  which  sets  the  guidelines  tor  the  milestone  review  process.  Preparing  tor  a  DAB 
Committee  Review  is  a  continuous  process.  However,  there  are  specific  events  which  must  take  place 
in  order  to  have  a  successful  review. 

The  process  of  planning  tor  a  committee  review  is  initiated  by  informal  discussions  between  the 
Office  of  the  USD(A)  and  DOD  Component  personnel  and  by  reference  to  the  long-range  schedule 
published  by  the  DAB  Executive  Secretary.  This  schedule  identifies  the  requirement  to  conduct  a  DAB 
review  based  on  a  program  schedule,  as  nxxJified  by  actual  events. 

A  planning  meeting  held  not  later  than  166  days  prior  to  the  committee  review  assesses  program 
progress  and  confirms  documentation  requirements.  Results  of  this  meeting  are  document^  in  the 
committee  memorandum. 

a.  DURATION:  Regulatory  time  frames  are  included  in  the  ’DESCRIPTION  and  PLANNING 
GUIDANCE'  paragraphs  above. 

b.  CONSTRAINTS:  Schedule  can  be  a  constraint.  White  policy  now  advocates  an  event  driven 
schedule,  it  is  not  uncommon  that  there  is  a  schedule  driven  timetable  due  to  User  need,  the  budget 
cycle,  congressional  direction,  etc. 

c.  RESOURCES:  An  individual  is  needed  to  monitor  status  of  the  milestone  review  process. 
However,  several  members  need  to  be  involved  in  actually  preparing  tor  the  Committee  Review. 

d.  LESSONS  LEARNED: 

(1 )  When  the  B1  Program  Office  prepared  tor  a  Committee  Review,  they  immediately  contacted 
the  Committee  Review  Chair  staffers  to  monitor  program  concerns  and  issues  and  Committee 
requirements.  Unfortunately,  they  were  advised  by  these  staffers  that  they  would  handle  all  concerns  at 
the  DOD  level  and  there  would  not  be  any  need  for  the  Program  Office  to  interact  with  other  DOD 
offices.  While  these  staffers  did  try  to  control  DOD  questions  and  concerns,  they  in  fact  had  no  authority 
over  the  other  offices  and  were  not  really  in  tune  with  the  concerns  of  the  Committee  members.  The 
office  of  PA&E  especially,  had  several  concerns  that  could  have  been  alleviated  prior  to  the  Committee 
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Review.  Therefore,  it  is  highly  recommerKled  that  the  Program  Office  interact  cfirectly  with  each  ot  the 
Committee  member  offices  to  preclude  last  minute  surprises  during  the  Committee  Review. 

(2)  Following  the  F-22  DAB  briefing  there  was  a  28  Jan  92  offsite  meeting  on  the  DAB  review 
process  as  an  outbrief  for  the  DAB.  Problems  identified  wth  Committee  Reviews  were  identified  and  the 
following  recommendations  were  offered: 

Continue  to  press  Services  for  strictly  issue  oriented  briefings  -  no  marketing  at  committee 

reviews 

Elevate  issues  to  principals  as  soon  as  possible  ■  donl  wait  until  DAB  to  have  principals  weigh 
in. 

OSD  presentation  format  should  be  Chairman's  prerogative. 

Single  briefer  makes  for  a  well-structured  meeting. 

Multiple  briefers  force  each  functional  manager  to  "own*  his  issue. 

Committee  Chairman  to  decide  on  case  by  case  basis. 

API  Input:  Strive  for  consistency  among  three  committees. 

e.  BEST  PRACTICES:  All  involved  parties  (at  all  levels  from  Product  Center,  USAF,  and  OSD) 
need  to  get  involved  early  in  the  Milestone  Review  process  in  order  to  achieve  a  successful  Committee 
Review. 


f.  TRAPS:  Don1  wait  until  a  few  weeks  before  the  Committee  Review  to  assess 
documentation/programmatic  needs.  Involvement  needs  to  occur  prior  to  the  planning  meeting.  Don1 
try  to  market  the  program.  This  is  not  a  “salesmanship”  review.  Stay  with  the  focused  review  items. 
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1.  ELEMENT:  A21 .  TBS  1 .4.09.4  (IFC  Rev.  93-3) 

2.  ELEMENT  TITLE:  Write  Integrated  Pro<^  Assessment  (IPA)  (OSO) 
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3.  ELEMENT  OWNER(S):  Strategic  Systems  Committee  (SSC),  Conventional  Systems  Committee 
(CSC),  and  Command.  C^rol,  Communications,  and  lntelligefx»  Systems  Comrnittee  (C3ISC) 

4.  ELEMENT  STAKEHOLDER(S): 

OSD:  USD(A) .  OUSD(  TS).  OUSD{S&SS).  Dir.  AP&PI.  Dep  Dir  ASM.  DDR&E.  ASD(C3I).  DASD(C3). 
DAB.  CSC.  SSC.  C3ISC 

DOD  COMPONENTS:  Dept  of  Army  (ASA(ROA).  SARD-ZBA).  Dept  of  Navy  (ASN(RDA).  Dir.  RE),  and 
Dept  of  Air  Force  (SAF/AQ.  SAF/AQX) 

5.  REQUIREMENT:  DODI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures.  23  Feb 
91 ,  p.  2-7,  para,  c.1 .  Outlines  the  milestone  review  documentation  concept. 

6.  PURPOSeOBJECTIVES: 


a.  Purpose:  Provides  the  basis  for  the  Milestone  Decision  Review.  For  a  Defense  Acquisition 
Board  (DAB)  designated  potential  program,  the  IPA  documents  the  recommendations  of  the  Review 
Committee  as  part  of  the  milestone  decision  process. 

b.  Objective:  To  summarize  the  results  of  the  independent  assessments  conducted  by  the 
supportirtg  staff  and  review  forums. 

7.  DESCRIPTION:  The  IPA  documents  OSD's  independent  assessment  of  the  potential  program  which 
is  accomplished  during  the  Committee  Review  (A20).  It  follows  the  format  of  the  Integrated  Program 
Summary  (IPS),  whose  format  and  content  are  outlined  in  DOD  5000 .2M,  Part  4  (D68). 

Within  5  days  after  the  (k)mmittee  Review  for  Milestone  1 ,  the  ComrrMee  staff  specialist  should 
prepare  the  IPA  (which  is  the  Committee  Chair's  report),  and  a  forwarding  memorandum  which  will  be 
submitted  to  the  Defense  Acquisition  Board  (DAB)  Chair.  Coordination  of  this  document  with  Committee 
principals  should  be  accomplished  within  2  working  days  (Ref:  DODI  5000.2,  p.  13-B-6,  para.  c).  The 
IPA  should  include  recommendations  to  the  DAB  on  the  merits  of  proceeding  with  the  program,  proposed 
cost-schedule-performance  trade-offs,  and  proposed  ex4  criteria  for  the  next  acquisition  phase.  (Ref: 
DODI  5000.2,  p.  13-A-12,  para.  4.b.(g)4).  The  IPA  is  used  to  support  the  DAB  review  (A^). 

8.  ENTRANCE/EXIT  CRITERIA: 

Entrance:  This  element  begins  when  the  committee  review  is  complete  and  recommendations  are 
available  to  document  in  the  IPA  (Block  A20,  Conduct  Committee  Review  (OSD)). 

Exit:  This  element  ends  when  the  IPA  has  been  approved  (Ref:  DODI  5000.2,  p.  1 1-C-2,  para.  3) 
and  sent  to  the  DAB  chair  (Block  A22,  Conduct  DAB  Milestone  1  Review). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  IPS  fSubmH  Final  US  /  Does  (Air  Farce).  A 19) 

b.  Output:  Issued  IPA  (A21) 
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10.  KEY  REFERENCES: 

a.  DOOl  5000.2,  Defense  Acquisition  Management  Policies  and  Proceduies,  23  Feb  91 .  Chapter 
13.  Outlines  Defense  acquisition  procedures  and  documentation  requirements. 

b.  DOD  S000.2M,  Defense  Acquisition  Management  Documentation  and  Reports.  February 
1991 ,  Part  4.  Provides  the  format  of  the  IrMegrated  Program  Summary  (which  is  the  format  for  the 
Integrated  Program  Assessment). 

11.  IMPLEMENTATION  TOOLS:  None  known. 

12.  PLANIRNG  GUIDANCE:  For  IPA  preparation  format  see  DoD  5000.2M,  Part  4. 

a.  DURATION:  Per  regulation,  it  should  take  no  kmger  than  5  days  to  complete  the  IPA. 

b.  CONSTRAINTS:  None  known. 

c.  RESOURCES:  An  OSD  committee  staff  specialist  is  needed  to  prepare  for  the  Committee 
Review,  document  the  results  of  the  Committee  Review,  artd  prepare,  coordinate  and  distribute  the  IPA. 
A  Committee  Review  Chairman  is  responsible  to  conduct  the  Committee  Review  and  sign  the  IPA. 
Resources  are  not  required  for  this  effort  within  the  project  office.  However,  the  Project  Manager  should 
be  aware  of  the  status  and  content  of  the  IPA. 

d.  LESSONS  LEARNED;  Following  the  F-22  DAB  briefing  there  was  a  28  Jan  92  offsite  meeting  on 
the  DAB  review  process  as  an  outbrief  for  the  DAB.  At  this  offsite  meeting  several  problems  were 
iderMified  with  Committee  Reviews.  These  problems  included  timeliness,  transition  to  IPA  format,  and  a 
lack  of  identification  of  who  would  represent  OSD(P&L)  at  the  Committee  Review.  The  offsite  members 
recommended  early  drafting  (pthk  to  Committee  Review)  of  the  IPA  to  facilitate  timely  submission 
following  Committee  Review.  Further,  it  was  recommended  that  the  Committee  Chair  be  responsible  to 
press  on  with  implementation  of  the  IPA  format  to  include: 

-  Acknowledgment  that  an  independent  cost  estimate  is  a  critical  new  dimension 

-  A  cover  letter  which  should  address  big  issues,  and 

-  Segregation  of  new  issues  from  those  previously  identified. 

The  (rtfsite  members  also  recommended  that  the  Chairperson  consider  folding  separate  inputs 
from  DAB  prirKipals  into  the  IPA  versus  irKluding  them  in  a  separate  DAB  blue  book.  Principals  could 
then  concur  with  positions  as  represented  in  the  IPA.  However,  separate  inputs  are  still  needed  at  the 
Committee  Review,  and  Committee  Chairman's  director  and  staff  specialists  must  integrate  staff 
products. 

The  offsite  also  recommended  that  we  need  to  gain  experience  before  we  make  assessments, 
and  recognize  that  baselines/exit  criteria  philosophy  and  implementation  are  still  evolving.  Their  biggest 
concerns  were  the  measures  of  effectiveness  (MOE)  and  consistency  as  well  as  the  time  needed  to  work 
with  clarified  guidance. 


e.  BEST  PRACTICES:  Early  drafting  (prior  to  Commihee  Review)  of  the  IPA  should  facilitate 
timely  submission  following  Committee  Review. 

The  Committee  staff  specialist  needs  to  be  aware  of  programs  and  their  associated  IPS  documents 
which  are  considered  by  the  OSD  Committee.  Familiariz^ion  with  content  and  format  requirements  for 
the  IPA  is  recommended  prior  to  attending  any  Committee  Review. 
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I.  TRAPS:  Lack  of  preparation  and  involvement  prior  to  and  during  the  oommiitee  review  wi 
make  it  dMcutt  to  prepare  a  useKit  IPA.  (This  applies  to  prefect  office  personnel  as  weK  as  OSD 
participants.) 
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1.  ELEMENT:  A22.  TBS  1.4.11.0/1.4.12.1  (IFC  Rev.  93-3) 

2.  ELcMENT  TITLE:  Conduct  OAB  Milestone  I  Review 

3.  ELEMENT  OWNER(S):  Under  Secretary  of  Defense  for  Acquisition  (USO( A)) 

4.  ELEMENT  STAKEHOLOER(S):  OAB  Principals  &  Participants,  PEO,  and  Project  Manager 

5.  REQUIREMENT:  DOD  Directive  5000.49,  Defense  Acquisition  Board.  1 1  Sep  89.  Outlines  the 
responsibilities  and  membership  of  the  Defense  Acquisition  Board.  DODI  5000.2  Part  2/3  provides 
requirements  that  need  to  be  met  prior  to  MS  I.  Part  13-A  provides  DAB  procedures. 

6.  PURPOSE/OBJECnVES: 

a.  Purpose:  The  Defense  Acquisition  Board  (DAB)  recommends  to  the  USD(A)  whether  or  rxit  a 
DAB  designated  program  should  be  granted  demonstration/validation  approval. 

b.  Objective:  To  identify  whether  or  not  a  project  should  proceed  into  the  next  appropriate 
acquisition  phase  based  upon  issues,  affordability,  alternatives,  trades,  and  exit  criteria. 

7.  DESCRIPTION:  The  OAB  Milestone  Review  is  the  last  major  review  of  a  project  as  a  part  of  the 
review  and  approval  of  a  project  to  allow  the  Milestone  Decision  Authority  to  d^i^  whether  or  tx>t  a 
project  should  proceed  into  Phase  I,  Demonstration  and  Validation  (or  other  phases  as  appropriate)  of 
the  acquisition  process.  During  this  review,  the  recommerxfations  tased  upon  the  Committee  Review 
(A20)  as  documented  in  the  IPA  (/^1 )  are  reviewed.  The  final  decision  doojmented  in  the  Acquisition 
Decision  Memorandum  is  the  basis  for  preparation  of  the  Program  Management  Directive  (PMD)  (B25). 

•  The  Office  of  the  Secretary  of  Defense  (OSD)  Committee  Chair  sets  the  tone  of  the  DAB  meeting  by 

summarizing  the  issues  and  recommendations  from  the  OSD  Committee  Review.  It  is  then  the  Project 
Manager's  (PM's)  job  to  convince  the  DAB  that  all  feasible  alternatives  have  been  considered  and  the 
proposed  study  altemative(s)  is/are  reasonable  given  the  risks  associated  with  the  program.  Therefore, 
the  PM  briefing  should  focus  on  issue  resolution  and  risk  management  and  should  highlight  overall 
program  status.  The  DAB  will  expect  the  following  questions  to  be  addressed: 

Where  are  we? 

Where  are  we  going? 

What  risks  exist? 

Is  what  we  plan  to  do  affordable? 

Is  the  requirement  being  met? 

The  PM  briefing  should,  therefore,  address  all  known  OSD  issues  especially  those  issues  addressed 
at  the  0>mmittee  Review.  This  forum  is  not  the  place  for  the  PM  to  tell  the  DAB  what  a  wonderful  job 
he/she  is  doing.  Addressing  all  special  interests  of  DAB  participants  will  increase  the  chances  of  a 
favorable  decision.  It  is  possfole  to  receive  program  approval  without  convening  the  DAB,  if  there  are  no 
OSD  issues  resulting  from  the  OSD  Committee  Review. 

The  scope  and  formality  of  the  review  will  depend  on  the  specific  project  issues.  It  is  important  to 
keep  in  mind  that  alt  projects  are  different.  The  proposed  program  baseline  (cost,  schedule  and 
performarxto),  proposed  program  execution  status,  and  proposed  program  plans  should  be  presented  by 
the  PM.  Affordability  should  also  be  addressed  in  a  program  context.  In  addition,  trade-offs  considered 
should  be  presented.  It  will  be  the  PM's  job  to  build  confidence  in  the  proposed  acquisition  approach  and 
program  plan.  For  known  areas  of  risk  (cost,  schedule  and  performarK:e),  the  PM  should  describe  how 
risk  will  be  managed.  The  DAB  will  be  very  interested  in  risk  management.  The  PM  must  convince  the 
DAB  that  all  risk  has  been  identified  and  will  be  properly  managed. 
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The  PM  can  recommend  the  ahernative{s)  to  be  pursued,  but  should  present  aH  leasibte  alterriatives. 
It  will  be  the  PM's  job  to  convince  the  DAB  prindpals  that  the  allemative<s)  recommended  is/are  the  best 
choice.  The  USD(A)  (based  upon  the  DAB's  recommendations)  has  approval  authority  for  the  actual 
altemative(s)  to  be  pursued  in  the  following  acquisition  phase.  It  is  in  the  best  inlerest  of  the  PM  to 
present  proposed  exit  criteria,  even  though  the  USO(A)  ultimately  approves  the  exit  criteria. 

Members  of  the  Board  (as  defined  in  DoOD  5000.49)  include: 

USD(A)  -  Chair 

Vice  Chairman,  Joint  Chiefs  of  Staff  -  Vice  Chair 

Director,  Defense  Research  and  Engineering 

Service  Acquisition  Executive,  Army 

Service  Acquisition  Executive,  Navy 

Service  Acquisition  Executive,  Air  Force 

Director  Program  Analysis  and  Evaluation 

Comptroller,  Department  of  Defense 

Director,  Operational  Test  and  Evaluation 

Chair  of  the  cognizant  DAB  Committee,  as  appropriate 

Other  participants  in  the  DAB  include  the  DAB  Executive  Secretary  who  will  attend  all  DAB 
meetings,  the  Director  Defense  Procurement,  Director  API,  General  Counsel,  the  responsible  PM  and 
Program  Executive  Officer  (PEO)  and  any  representatives  from  DOD  Components  or  other  Government 
Agencies  if  the  Chair  determines  that  the  presence  of  the  representative  is  appropriate  because  of  the 
specific  issues  urxfer  consideration.  For  example,  the  DAB  Chair  will  invite  foe  Under  Secretary  of 
Defense  for  Policy  and  the  Assistant  Secretary  of  Defense  (Force  Management  and  Personnel)  to 
participate  in  DAB  activities,  whenever  those  activities  affect  matters  within  their  respective 
responsibilities.  DAB  participation  is  highly  dependent  on  the  DAB  Chairman  and  will  vary  by  who  chairs 
the  DAB. 

An  OSD  Action  Officer  (OSD/AO)  is  assigned  to  work  each  project  to  go  before  the  DAB,  and  there 
are  several  advisors  to  the  DAB.  For  example,  the  Director  of  the  Defense  Intelligence  Agency  (DIA) 
serves  as  the  principal  advisor  on  intelligence  matters.  (The  responsibilities  and  authorities  of  the  DAB 
Chair  and  Vice  Chair  are  outlined  in  DOD  Directive  5000.49.) 

In  addition  to  performing  Milestone  Reviews,  the  DAB  may  also  perform  other  periodic  reviews  at 
USD(A)  (and  occasionally  Congressional)  direction.  It  is  impcfoant  to  keep  in  mind  that  DAB  approval  is 
often  necessary  in  order  to  award  contracts,  obtain  funding,  and  proceed  into  the  next  acquisition  phase. 
Therefore,  it  is  critical  that  the  PM  understand  the  purpose  and  fonctioning  of  the  DAB.  Further,  to  be 
successful  at  a  DAB  review  requires  extensive  knowledge  of  foe  issues  at  OSD.  Therefore,  the  PM  must 
work  very  closely  with  the  OSD/AO  as  well  as  the  representatives  of  the  DAB  princ^ls. 

Upon  completion  of  the  DAB  Milestone  Review,  an  action  officer  in  OSD/USD(A)/ API/ASM  is 
responsible  for  preparing  the  ADM  to  reflect  the  USD(A)'s  direction.  The  ADM  is  then  coordinated 
through  APIand  the  Committee  Chair  arfo  then  is  forwarded  to  the  DAB  members  for  review.  DAB 
members  have  24  hours  to  comment  on  the  ADM  after  which  the  ADM  is  sent  to  the  USD(A)  for 
signature.  (By  regulation,  the  ADM  is  signed  by  the  USD(A)  within  48  hours  after  the  DAB  review.) 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  ENTRANCE:  This  activity  will  not  begin  until  the  appropriate  OSD  Committee  has  reviewed  the 
program  (Block  A20,  Corxfuct  Committee  Review  (OSD)). 

b.  EXIT :  Activity  for  this  effort  is  complete  when  the  ADM  has  been  approved  and  distributed. 
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9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  Data  needed  for  the  DAB  review  include  the  Read-Ahead  (also  called  the  'Blue  Book"  - 
which  includes  pertinent  project  documentation  and  briefings)  and  the  Integrated  Program  Assessment 
(IPA)  (which  documents  the  issues  and  recommendations  of  the  OSD  Committee  Review)  (Write  IPA 
(OSD).  A21). 

b.  Output;  The  approved  ADM.  The  ADM  documents  the  decisions  of  the  USD(A).  It  will; 

(1)  Approve  the  initiation  of  a  new  program  and  entry  into  Phase  I.  Demonstration  and 
Validation.  (2)  Approve  the  proposed  or  modified  acquisition 

strategy  (and  Concept  Baseline  for  Phase  1 ). 

(3)  Establish  program-specific  exit  criteria  that  must  be  accomplished  during  Phase 
I/modification.  (4)  Identify  affordability  constraints  derived  from  the 

planning,  programming,  and  budgeting  system.  (Sample  ADM  for  Milestone  II  decision  is  attached). 

10.  KEY  REFERENCES: 

DODI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  Feoruary  23, 1991 .  Parts 
3,  7 1  &  13.  Outlines  the  procedures  for  DAB  review  and  milestone  decision. 


11.  IMPLEMENTATION  TOOLS:  The  ALLCARS  P.  C.  Lessons  Learned  Data  Base  and  the  Air  Force 
Acquisition  Management  Data  Base  managed  by  ASC/CY,  WPAFB  OH,  DSN  785-1427. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  See  "Description"  and  “Lessons  Learned." 

b.  CONSTRAINTS:  The  DAB  will  not  normally  convene  until  the  appropriate  OSD  Committee  has 
reviewed  the  program,  and  an  ADM  cannot  be  generated  until  a  decision  has  been  made  by  the  USD(A). 

c.  RESOURCES:  Individuals  will  be  needed  to  interface  with  the  OSD  action  officers  as  well  as  the 
DAB  participants.  These  individuals  should  be  knowledgeable  in  the  program  and  the  DAB  process.  The 
number  of  individuals  required  will  vary  based  upon  the  complexity  of  the  program  and  the  number  of 
OSD  issues. 

d.  LESSONS  LEARNED: 

(1)  While  DODI  5000.2  infers  that  exit  criteria  will  be  included  in  the  ADM,  it  is  possible  that 
the  project  office  will  be  requested  to  provide  exit  criteria  after  issuance  of  the  ADM.  As  an  example,  the 
F-22  project  was  requested  to  propose  exit  criteria  no  later  than  30  days  after  clarification  of  exit  criteria 
guidance.  This  was  appropriate  for  the  F-22  effort  because  they  were  going  into  DenrWal  and  needed 
commitments  from  contractors  before  they  committed  to  exit  criteria.  This  is  evidence,  however,  that 
project  offices  should  be  prepared  to  recommend  exit  criteria  and  the  point  in  time  when  it  is  most 
appropriate  to  commit  to  exit  criteria. 

(2)  DOD  Instruction  5000.2  recommends  allowing  6  months  to  get  to  a  DAB  review.  Many 
programs  have  found  that  twice  that  time  is  required,  and  there  is  at  least  one  project  that  took  about  3 
years. 
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e.  BEST  PRACTICES: 

(1 )  The  keys  to  a  successful  DAB  include  a  ‘can  do‘  attitude,  being  proactive,  adapting  to  the  I 

process,  and  remaining  flexible.  Interact  with  all  key  players  early  and  continuously  throughout  the 

process.  Discourage  the  introduction  of  issues  whi^  are  not  pertinent  based  upon  the  timing  of  the 

project.  (For  example,  if  future  phases  are  anticipated,  contain  discussions  to  the  relevant  phase  for 

decision.)  Work  very  closely  with  the  OSD/ AOs,  but  do  not  neglect  cbse  interaction  with  action  officers 

of  other  DAB  principals  and  key  OSD  offices.  While  the  OSD/AOs  are  key  in  coordinating  the  DAB 

preparation  activities,  they  do  not  necessarily  know  the  issues  and  hidden  agendas  of  the  DAB  principals  I 

and  OSD  staff. 

(2)  Take  all  OSD/AO  concems/issues  seriously,  no  matter  how  painful.  Mention  the 
concems/issues  in  your  briefing  to  the  DAB  and  state  your  planned  commitment  to  work  them  (ALLCARS 
P  C.  Lesson  91). 

• 

(3)  Set  up  a  DAB  OSD/AO  working  group  .n  the  Pentagon,  with  project  office  ,  PEO,  and 
selected  user  participation.  This  will  set  the  stage  for  informing  each  DAB  member  fulty/earty  in  the 
process  (ALLCARS  P.  C.  Lesson  91 ).  Meet  at  least  monthly.  A  continual  interaction  with  SAF/PEO  (or 
DAC)  and  OSD  staff  is  imperative. 

(4)  Effective  interaction  among  the  requirements  generation,  acquisition  management  artd  • 

planning,  programming  and  budgeting  system  is  essential  for  program  success. 

(5)  Use  experts  to  help  work  issue  resolution  in  real  time,  ask  for  advice,  coordinate  early,  and 
be  proactive  as  much  as  possible. 

(6)  Have  a  contingency  for  exte'^xJing/continuing  the  current  program  phase  if  the  DAB  does  B 

not  make  a  prompt  decision  to  proceed. 

f.  TRAPS:  Many  DAB  participants  and  OSD  agencies  have  their  own  issues  and  hidden  agendas 
which  if  not  addressed  could  result  in  surprises  and  program  delays.  In  addition  the  DAB  may  require 
their  approval  before  RFP  release  or  contract  award.  This  can  affect  program  schedule. 
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1.  ELEMENT:  A23.  TBS  1.4.03.2  (IFC  93-3) 

\ 

2.  ELEMENT  TITLE:  Conduct  DAB  Planning  Meeting  (OSD) 

1 

■m 

3.  ELEMENT  OWNER(S):  OSD/AP&PI/ASM 

4.  ELEMENT  STAKEHOLDER(S):  Operating  Command,  Product  Center,  SAF/AQXA,  Implementing 
Command,  and  PEO/DAC. 

5.  REQUIREMENT:  DoDI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 

91 ,  Part  1 3,  Sections  A  and  B,  describes  the  requirements  and  time  frames  for  the  Planning  Meeting,  the 
Committee  MenrK),  and  the  Master  Planning  Calendar. 

» 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose.  The  purpose  of  the  Defense  Acquisition  Board  (DAB)  Planning  Meeting  is  to  assess 
project  progress  toward  satisfying  Phase  0  exit  criteria  and  minimum  required  accomplishments  and  the 
readiness  of  the  project  to  proceed  into  Phase  1.  (Detailed  information  regarding  the  entire  DAB  review 
process  and  time  frames  can  be  found  in  DoDI  5000.2,  Part  13,  Section  B.) 

» 

b.  Objectives;  Documentation  requirements  will  be  confirmed,  documentation  plans  will  be 
assessed,  and  a  detailed  master  planning  calendar  set.  Issues  pertaining  to  the  Phase  0  exit  criteria  and 
minimum  required  accomplishments  arising  from  the  assessment  of  project  progress  and  documentation 
plans  will  be  identified  and  documented  in  the  Committee  Memo. 

» 

7.  DESCRIPTION: 

• 

a.  The  DAB  Milestone  Review  process  begins  with  a  planning  meeting  held  at  least  180  days 
prior  to  the  DAB  milestone  review.  There  will  be  only  one  Planning  Meeting  held,  depending  on  whether 
the  acquisition  is  to  go  through  the  Air  Force  Systems  Acquisition  Review  Council  (AFSARC)  and  DAB  or 
AFSARC  only.  If  the  project  is  going  to  the  AFSARC  only,  refer  to  Data  Sheet  B19,  Conduct 

AFSARC/DAB  Planning  Meeting  (AF).  The  information  required  for  this  meeting  is  as  follows: 

• 

(1)  Draft  Cost  Analysis  Requirements  Document  (CARD)  (D72) 

► 

(2)  Proposed  Integrated  Program  Summary  (IPS)  Outline  (D68) 

(3)  Status  of  progress  toward  satisfying  exit  criteria  as  defined  in  the  Milestone  0 

Acquisition  Decision  Memoraridum  (ADM) 

(4)  Status  of  progress  toward  satisfying  the  minimum  required  accomplishments  as 
defined  in  DoDI  5000.2,  Part  3,  Page  3-8 

I 

(5)  Any  potential  issues 

(6)  Schedule  of  efforts  to  be  accomplished  to  get  to  the  DAB 

» 

(7)  Project  status 

(8)  Status  of  all  documentation  needed  for  a  Milestone  1  decision 

b.  The  planning  meeting  is  chaired  by  the  relevant  DAB  Committee  Chair  (or  a  representative) 
and  will  include  representatives  from  each  Committee  principal  and  DoD  Component.  The  Project 

Director  may  attend  if  desired  by  the  Committee  Chair. 

» 

_ 
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c.  As  a  result  of  the  planning  meeting,  the  Committee  staff  specialist  prepares  a  Committee 
Memo  for  the  Committee  Chair's  signature  within  7  days  of  the  meetir^.  This  memorandum  goes  to  the 
Under  Secretary  of  Defense  for  Acquisition  and  to  the  Air  Force  Acquisition  Executive  (AFAE)  and 
highlights  the  results  of  the  assessment  of  project  progre^ and  contains  a  recommendation  as  to 
whether  or  not  the  Milestone  Review  should  be  held  as  planned.  It  also  identifies  issues  pertaining  to  the 
exit  criteria  and  minimum  required  accomplishments  that  Committee  members  recommended  be 
addressed  in  the  program  documentation  for  Milestone  I  (D€8).  Also,  as  a  result  of  this  meeting,  the 
CARD  will  be  forwarded  for  the  Component  Cost  Analysis  effort  (B21 ). 

d.  The  Committee  staff  specialist  also  prepares  a  master  planning  calendar  which  can  be  used 
as  a  management  tool  throughout  the  Committee  and  DAB  preparation  process.  This  calendar  is 
distributed  initially  with  the  Committee  Memo  and  updated  and  redistributed  to  OSD  and  DoD 
Component  personnel  throughout  the  process. 

8.  ENTRANCOEXIT  CRITERIA: 

a.  Entrance:  The  process  of  planning  for  a  Committee  review  is  initiated  by  informal 
discussions  between  the  Office  of  the  Under  Secretary  of  Defense  for  Acquisition  and  Technology  and 
DoD  Component  personnel  and  by  reference  to  the  long-range  schedule  published  by  the  DAB  Executive 
Secretary.  This  schedule  identifies  the  requirement  to  conduct  a  DAB  review  based  on  project  schedule, 
as  modified  by  actual  events  and  the  availability  of  the  participants. 

b.  Exit;  The  event  is  completed  upon  submission  of  the  Committee  Menx>. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  Government  and  Contractor  provide  project  status  information  (see  Para  7.a.) 

Draft  CARD  (D72) 

Proposed  IPS  CXitline  (D67) 

b.  Outputs:  Committee  Memo 

Master  Planning  Calendar 

10.  KEY  REFERENCES: 

a.  Air  Force  Acquisition  Model  (AFAM) 

b.  PEM/Action  Officer  Handbook,  Apr  92,  Paragraph  B.4  and  subs.  Describes  the 
AFSARC/DAB  process. 

c.  Draft  AF  Sup  1  to  DoDI  5000.2,  Aug  92,  Part  13A,  Atch  1 ,  Para  4.a.  Further  clarifies 
recpiirements  for  AFSARC/DAB  Planning  Meeting. 

11.  IMPLEMENTATION  TOOLS:  None  identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Allow  for  2  weeks  preparation  time  to  "test  the  waters”  for  current  mood  of  the 
staff,  current  trends  in  direction/questions,  and  to  gather  up-to-the-minute  current  status  on  the  project 
and  known  problems.  Attendance  is  about  one  half  day  in  the  Pentagon.  Follow-up  until  the  Guidance 
Memorandum  is  signed. 
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b.  COf^RAMTS: 


(1 )  Lack  of  current  information  on  project  status 

(2)  Project  schedule  slippages 

(3)  Generjiting  a  review  schedule  that  can  be  supported  by  the  parties  involved 

c.  RESOURCES:  The  resources  should  include  a  conference  room  erf  appropriate  size  to 
accommodate  the  number  of  attendees  for  the  Planning  Meeting,  an  operating  vu-gr^  machine  and  a 
back-up,  an  individual  to  flip  the  charts  as  the  briefer  presents  his/her  charts,  and  a  secretary  taking 
notes  to  ensure  that  all  comments,  questions,  changes,  etc.  are  adequately  and  clearly  documented  for 
the  resultant  memo  that  will  be  issued  upon  completion  of  the  meeting. 

d.  LESSONS  LEARteO: 

(1)  In  the  area  of  DAB  requirements,  taskings,  briefings,  and  other  associated  events,  it 
is  an  absolute  necessity  to  have  control  and  authority  over  the  process.  It  is  imperative  that  personnel 
working  DAB  issues  must  become  the  experts  and  be  proactive. 

(2)  Be  sure  the  purpose  of  the  DAB  is  clearly  defined  as  to  what  is  required  by  the 
Milestone  Decision  Authority  (MOA) 

(3)  Don't  go  to  the  Planning  Meeting  without  an  Operational  Requirements  Document 
(ORD),  documents  in  draft  form,  or  an  approved  acquisition  strategy. 

e.  BEST  PRACTICES: 

(1 )  Form  a  team  to  develop  a  strategy/plan  to  obtain  a  successful  DAB  resolution.  This 

team  should; 


(a)  Identify  requirements  for  a  Milestone  DAB 

Create  and  track  briefings  to  support  DAB  requirements 

(b)  Resolve/close  programmatic  issues  early 

Idenmy  DAB  issues  and  recommend  solutions  to  SPO  director 

(c)  Prepare  documentation  to  include  pre-coordination  with  the  OSD  staff,  the 
Air  Staff,  and  other  offices  as  appropriate. 

Write  and  track  DAB  documentation 

(2)  The  F-22  SPO  formed  their  DAB  team  16  months  prior  to  their  Milestone  Decision. 
Their  team  had  three  objectives:  (1)  Develop  a  DAB  documentation  tracking  system,  (2)  Identify  and 
resolve  issues/concems  that  could  affect  a  successful  Milestone  DAB  decision,  and  (3)  Keep  the 
Program  Director  informed  on  all  issues.  Also,  based  on  the  timeline  identified  in  Section  13A  of  DoD 
5000.2,  the  F-22  SPO  developed  an  internal  schedule  to  trar*  events/milestones  leading  up  to  the 
Milestone  DAB  decision.  This  schedule  proved  to  be  an  invaluable  top-level  planning  tool  to  satisfy 
milestone  requiremerrts. 

(3)  Attendance  at  the  Planning  Meeting  by  the  Project  Director  is  not  required,  but  is 
allowed.  It  is  highly  desirable  for  the  Project  Director  to  attend  because  he/she  has  the  knowledge  of  the 
full  breadth  of  the  program  and  may  be  ^le  to  answer  specific  questions  which  may  avoid  extensive 
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wriRen  explanations  on  a  "non-issue.’  Therefore,  it  is  recommended  that  the  Project  Director  coordinate 
with  appropriate  parties  to  obtain  authorization  to  attend  ptarviing  meetings. 

(4)  There  is  an  extremely  large  volume  of  point  papers,  briefing  charts  arxl  documents  ^ 

to  prepare.  The  Project  Director  should  i^ntify  a  senior  (Lt  Col  or  GS/GM-14),  experienced  (preferably 
level  III)  acquisition  manager  as  the  full  time  OPR  for  the  AFSARC/DAB  preparation  on  his/h^  staff. 

That  in^idual  should  also  attend  the  Planning  Meeting,  if  mvited,  and  establish  himself/herself  w4h  the 
appropriate  action  officer  level  at  SAP  and  OSD.  He/she  must  proactively  interact  with  those  action 
officers  as  the  AFSARC/DAB  process  proceeds. 

• 

f.  TRAPS:  See  Lessons  Learned. 
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1.  ELEMENT:  B1 .  TBS  0.1. 1.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  Air  Force  Planning  Guidance 


Novas 


3.  ELEMENT  OWNER(S):  The  Secretary  of  the  Air  Force  (SAF),  and  the  Chief  of  Staff  of  the  Air  Force 
(CSAF) 

4.  ELEMENT  STAKEHOLOER(S):  Joint  Chiefs  of  Staff  (JCS),  the  Office  of  the  Secretary  of  Defense 
(OSD),  Theater  Commanders-in-Chief  (CINC),  the  Under  Secreta^  of  Defense  for  Acquisition  (USD(A)), 
Secretary  of  the  Air  Force  (SAF),  the  Assistant  Secretary  of  the  Air  Force  for  Acquisition  (SAF/AQ),  the 
Air  Force  Director  of  Operations  (AF/XO),  Operating  Commands  and  Field  Operating  Agencies  (FOAs). 

5.  REQUIREMENT:  DODD  5000.1,  Part  2,  para^aph  B.2 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  To  relate  the  President's  guidance  on  national  security  interests  and  OSD's 
Defense  Planning  Guidance  (DPG)  to  Air  Force  strategies  to  protect  these  national  interests. 

b.  Obiectives.  To  formulate  Air  Force  regional  plans  that  would  best  utilize  Air  Force  resources 
to  protect  national  interests. 

7.  DESCRIPTION:  After  OSD  and  JCS  receive  the  President's  National  Security  Strategy  of  the  United 
States,  they  produce  the  National  Military  Strategy  Document  (NMSD),  the  Joint  Strategic  Capabilities 
Plan  (JSCP),  and  the  Defense  Planning  Guidance  (DPG)  as  discussed  in  the  National  Defense  Planning 
process  (A1 ).  The  Air  Force  initially  gets  into  the  plannirtg  process  when  they  hold  a  strategy  review  that 
ensures  the  capabilities  arxl  attributes  of  air  power  are  incorporated  into  the  various  joint  strategy 
documents,  like  those  mentioned  above.  This  review  addresses  key  Air  Staff  and  CINC  level  issues  in 
preparation  for  the  development  of  the  Air  Force  executive  guidance  provided  by  the  SAF  and  CSAF, 
addressing  strategic  environment,  national  security  objectives,  defense  policy,  national  military 
objectives,  and  planning  priorities.  The  Air  Force  executive  guidance  is  used  to  influence  the  Joint 
Strategic  Capabilities  Plan  and  serve  as  the  Air  Force  input  to  other  joint  strategic  planning  system 
documents.  This  planning  process  eventually  results  in  the  publication  of  the  Air  Force  Planning 
Guidance  (AFPG)  in  the  summer  of  the  even-numbered  years,  which  includes  a  summary  of  the  Air 
Force  executive  guidarrce,  fiscally-constrained  force  stnjcture  levels  and  assessments  of  forces.  The 
AFPG  provides  the  link  between  DPG  planning  priorities,  fiscal  reality  and  potential  Air  Force  programs. 
The  AFPG  provides  the  strategic  inputs  to  the  Mission  Area  Assessment  "strategy-to-task"  process  (Cl) 
through  the  Operating  Command's  annual  review  of  the  mission  area  plans  (C4)  and  their  associated 
Concept  of  Operations  (C2). 
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8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  Receipt  of  the  National  Military  Strategy  Document,  Joint  Strategic  Capabilities 
Plan  and  Defense  Planning  Guidance. 

b.  Exit;  Publication  of  the  Air  Force  Plannir^  Guidance. 

9.  KEY  INPUTS/OUTPUTS: 

a.  Inputs:  National  MilKary  Strategy  Document  (At) 

Joint  Strategic  Capabilities  Plan  (At) 

Defense  Planning  Guidance  (At ) 

b.  Output;  Air  Force  Planning  Guidance 

10.  KEY  REFERENCES:  Air  Force  Instruction  10-601,  paragraph  1.1.2 

11.  IMPLEMENTATION  TOOLS:  None  identified 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  Defense  Planning  Guidance  is  published  in  late  fall  of  odd-numbered 
years.  The  Air  Force  Plannirrg  Guidance  is  then  published  following  the  DPG  in  the  summer  of  the  even- 
numbered  years.  Draft  guidance  is  supplied  in  the  off-years  for  planning  purposes. 

b.  CONSTRAINTS:  None  identified. 

c.  RESOURCES:  AFMC/XP  and  AFMC/XR  are  on  the  distribution  list  for  these  documents. 

d.  LESSONS  LEARNED:  None  identified 

e.  BEST  PRACTICES:  None  identified. 

f.  TRAPS:  None  identified. 
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1 .  ELEMENT:  B2,  TBS  0.1 .6.2.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Threat  Environment  Descriptions  (TEDS) 

3.  ELEMENT  OWNER(S):  HQ  USAF/IN 

4.  ELEMENT  STAKEHOLOER(S):  NAIC/TIA.  HQ  AFISAriNA,  DIA/DTI-AC,  USAF/XQR,  Product 
Center  Director  of  Intelligence,  SAF/AQ,  Operating  Command,  and  Implementing  Command 

5.  REQUIREMENT: 

a.  DoD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures, 

23  Feb  91 .  Part  4.  This  regulation  contains  poiicies  artd  procedures  for  productbn,  review^  and 
validation  of  intelligence  support  information. 

b.  AFR  200-13,  lnteiligerK:e  Support  to  the  Requirements  and  Acquisition  Processes,  1  Jul  90, 
Part  2.  This  regulation  states  the  Air  Force  policy  artd  requirements  for  threat  definition. 

c.  AFSCR  200-3,  Threat  Support  for  Systems  Acquisition,  5  Apr  85,  Attachment  1  (TEDs). 

This  regulation  contains  specific  guidance  on  preparing  threat  assessment  documents. 

6.  PURPOSEyOBJECTIVE(S): 

a.  Purpose;  The  TEDs  provide  a  reference  with  sufficiently  detailed  threat  data  in  a  mission 
area  to  support  planners  (C3)  and  program  or  research  offices.  This  intelligence  data  may  be  used  for 
planning,  system  engineering,  survivability  and  vulnerability  analysis,  threat  simulation  for  test  and 
evaluation,  QPSEC  and  CQMSEC  decisions,  and  technology  ex^oitation. 

b.  Objectives;  To  provide  sufficient  detailed  threat  data  to  assess  the  strengths  and  weaknesses 
of  current/future  military  force  used  by  the  Air  Force  to  aid  in  identifying  study  inputs  (C5),  to  support 
planners  in  developing  the  Mission  Needs  Analysis  (MNA)  (C3)  and  to  supped  the  Operating  Command 
in  writing  the  threat  portion  of  the  Mission  Need  Statement  (MNS)  (Cl 2). 

7.  DESCRIPTION: 

a.  TEDs  are  baselined  threat  documents  to  support  all  planning,  programming,  budgeting, 
development,  test  and  evaluation  activities,  and  are  associated  with  U.S.  Air  Force  mission  areas  and 
other  specialized  tasks.  MNS  drafters  (Cl  2)  are  supposed  to  include  a  brief  description  of  threat  in  the 
MNS  using  Defense  Intelligence  Agency  (DIA)  and  HQ  USAF/IN  approved  threat  information  (e  g., 
TEDs). 


b.  TEDs  support  System  Threat  Assessment  Reports  (STARs)  as  complementary  documents  by 
addressing  an  entire  Air  Force  mission  area,  thus  providirrg  a  breadth  and  scope  not  found  in  STARs 
(D50).  TEDs  may  also  serve  as  an  initial  basis  from  which  to  develop  a  STAR.  All  related  systems  in  a 
mission  area  are  supported  by  a  single  TED.  A  minimum  number  of  TED  documents  will  be  published 
consistent  with  AFMC  requirements. 

c.  National  Air  Intelligence  Center  (NAIC)  produces  the  TEDs  for  the  Air  Force  and  DoD.  TEDs 
are  produced  using  key  data  extracted  from  approved  intelligence  community  threat  information  (A2)  and 
publications  such  as  the  Defense  Intelligence  Projections  for  Planning,  Defense  Intelligence 
Assessments  and  Threat  Environment  Projections  (TEPs).  More  detailed  or  current  intelligence  data 
(not  yet  incorporated  in  Defense  Intelligence  Agency  (DIA)  and  Air  Force-approved  documents)  may  also 
be  used. 
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d.  TEDs  are  tailored  as  recHiired  lor  each  mission,  but  as  much  commonality  as  possible  is 

kept. 

e.  The  principat  volumes  of  the  TEDs  describe  the  threat  environment  by  time  period  (present 
up  to  20  years)  and  Region  of  the  World.  Weather  and  terrain  are  considered  to  determine  the  effect  on 
the  threat  eteinents. 

8.  ENTRANCE/EXrr  CRITERIA: 

a.  Errtrance:  This  activity  begins  when  validated  threat  information  is  available  to  support  the 
development  of  the  TEDs. 

b.  Exit:  This  activity  is  complete  when  the  DIA  validates  the  TEDs  for  publication  and 
distribution. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  Approved  intelligertce  publications  such  as  Defense  Intelligence  Projections  for 
Planning,  Defense  Int^igence  Assessments,  and  Threat  Environment  Projectbn  (TEPs). 

b.  Outputs; 

(1)  DIA  validated  TEDs. 

(2)  Assessments  of  the  strengths  and  weaknesses  of  current/future  military  force  used 
by  the  Air  Force  to  aid  in  identifying  study  inputs  (C5). 

(3)  Detailed  threat  data  in  a  mission  area  to  support  planners  for  the  MNA  (C3). 

(4)  Threat  descriptions  used  by  the  Operating  Command  to  write  the  threat  portion  of 

theMNS  (C12). 

(5)  Initial  basis  for  devetoping  STA(R)s  (050). 

10.  KEY  REFERENCES:  Air  Force  Instruction  10-601,  Mission  Needs  and  Operational  Requirements 
Guidance  and  Procedures,  16  Feb  93,  paragraphs.  1.1.4, 1.1.6,  and  1.1.7.  This  regulation  addresses 
MNA,  evolutionary  requirements  definition,  and  threat  assessment. 

1 1 .  IMPLEMENTATION  TOOLS:  The  threat  and  intelligence  data  base  which  consists  of 
validated  STARs,  Threat  Assessment  Reports  (TARs),  Threat  Planning  Documents  (TPDs),  TEDs. 
approved  Science  and  Technology  (S&T)  intelligence  reports,  and  other  intelligence  data,  such  as 
translations  of  foreign  research  reports  or  books. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Typically,  it  requires  approximately  12  months  for  NAIC  to  produce  the  TEDs. 
NAIC  publishes  the  TEDs  biennially,  and  maintains  currency  through  page  changes.  NAIC  will  ask  HQ 
USAF/INE  for  approval  of  page  changes  to  existing  TEDs  v^hin  a  reasonable  time,  consistent  with  the 
complexity  of  each  change.  Ten  to  1 5  days  for  minor  changes  and  30-45  days  for  complete  reissues  are 
typical. 
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b.  CONSTRAINTS:  Since  TEDS  are  used  to  support  the  MNS  development,  current  validated 
threat  data  is  a  necessity. 

C.  RESOURCES: 

(1)  NAIC/TIA  produces  the  TEDs  tor  ASC.  Each  TED  has  a  single  author.  However, 
they  have  help  from  many  people  and  organizations.  For  example.  HQ  USAF/INE  will  approve  new  or 
republished  TEDs  and  page  changes  to  existing  TEDs.  HQ  AFMC/INA  will  review  the  TED  change  in 
parallei  with  HQ  USAF/INE  and  comment  to  them.  The  DIA  will  validate  the  TEDs  (AS). 

(2)  Copies  of  the  TEDs  may  be  obtained  from  the  Product  Center  Director  of 
Intelligence  (Dl),  ASC/NAiC/TiA  for  ASC 

(3)  There  are  no  resources  from  the  project  team  needed  to  write  the  TEDs. 

However,  the  project  team  may  designate  a  point  of  contact  to  interface  with  the  Product  Center  Dl  to 
keep  up  to  date  on  threat  issues. 

d.  LESSONS  LEARNED:  Early  and  continued  collaboration  among  the  DIA  and  the  DoD 
Components  wiH  expedite  the  development,  review,  and  validation  of  threat  documentation  aixf  help  to 
ensure  the  availability  of  validated  threat  information  to  all  concerned  in  a  timely  manner. 

e.  BEST  PRACTICES: 

(1 )  Project  teams  should  strive  for  a  mutual  understanding  of  the  threat  process,  early 
involvement,  and  tailored  threat  support. 

*  (2)  When  extraordinary  threat  support  or  documentation  is  required,  the  project 

manager  allocates  resources  to  the  intelligence  proctocer  as  necessary. 

(3)  The  formation  of  a  Threat  Working  Group  (TWG)  is  an  effective  means  of  providing 
threat  support  to  any  project.  It  gives  advice,  guidance,  and  recommendations  to  the  project  team  on 
effective  responses  to  the  threat  environment.  The  TWG  should  include  representatives  from  the  project 
office,  the  using  commands,  and  the  appropriate  Director  of  intelligence  (Dl).  Normally,  this  group  is  not 
formed  until  after  MS  0.  However,  starting  this  function  upfrorrt  prior  to  MS  0  should  be  considered. 

Early  involvement  establishs  clear  lines  of  communication  and  aids  in  acquiring  timely  threat  support. 

(4)  For  more  specific  information  on  TEDs  contact  the  Product  Center  Dl 
(ASC/NAIC/TIA  for  ASC,  DSN  785-4285).  HQ  USAF  AFISA/INA,  DSN  225-7577.  is  the  Air  Force  Point 
of  Contact. 

f .  TRAPS:  Failure  of  the  project  team  to  evaluate  threat  data  sources  regularly  will  result  in 
information  for  the  MNS  that  is  neither  current  nor  accurate.  This  will  impact  the  validity  of  the  MNS. 
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1.  EUEMENT:  B5.  TBS  0.1.9.8  2  (IFC  93-3) 

2.  ELEMENT  TITLE;  Submit  Initial  POM^ES  Input 

3.  ELEMENT  OWNER:  Secretary  of  the  Air  Force  (SECAF) 

4.  ELEMENT  STAKEHOLDER(S);  CSAF,  AF/PE.  SAF/FM.  AF/XO,  Operating  Command,  and  Project 
Manager. 

5.  REQUIREMENT:  DoO  Directive  7045.14,  The  Planning.  Programming,  and  Budget  System  (PPBS), 
22  May  1964.  Describes  OSO  budget  process. 

6.  PURPOSEyOBJECnVES: 

a.  Purpose:  The  purpose  of  this  activity  is  to  create  approved  Air  Force  financial  planning 
documentation.  For  a  specific  project  office,  the  Program  Objective  Memorandum  (POM),  and  (to  a 
lesser  extent)  the  Budget  Estimate  Submission  (BES),  are  the  primary  opportunities  for  a  project  office  to 
submit  projerk/program  requirements  into  approved  Air  Force  planning  documentation. 

b.  Objectives:  The  objective  is  for  the  Air  Force  to  develop  a  comprehensive  and  integrated 
plan  which  supports  the  Defense  Planning  Guidance  (A1).  At  the  project  level,  it  should  be  the  objective 
of  the  project  office  to  get  the  program  financial  requirements  approved  at  the  earliest  opportunity  to 
prevent  schedule  delays  due  to  funding  availability. 

7.  DESCRIPTION: 

a.  The  development  of  the  Air  Force  Program  Objective  Memorandum  (POM)  is  the  process  by 
which  all  resources  required  to  execute  OSO  Defense  Planning  Guidance  (DPG)  are  documented  aixj 
validated.  The  POM  is  used  to  update  the  planning  for  the  6  years  contained  in  the  Future  Year  Defense 
Program  (FYDP).  After  OSD  adjustments  are  made  to  the  POM,  the  Air  Force  is  allowed  to  update  and 
reprice  the  projects  which  were  approved  .  This  is  documented  in  the  Budget  Estimate  Submission 
(BES),  which  emphasizes  the  first  2  years  of  the  FYDP,  and  converts  the  project  oriented  format  of  the 
POM  into  the  appropriation  categories.  At  this  phase  of  an  acquisition,  the  project  may  not  need  much 
funding,  but  if  the  project  could  require  funding  during  any  of  the  years  included  in  the  POM,  it  is 
essential  to  submit  a  POM  input. 

b.  The  FYDP  is  the  official  DoD  database  and  document  which  is  a  compilation  of  the  total 
resources  (forces,  manpower,  and  dollars)  programmed  for  DoD,  arranged  by  Major  Force  Program 
(MFP)  and  appropriation.  The  FYDP  projects  6  years  for  all  data  except  forces,  which  extend  an 
additional  3  years.  The  POM  submissions  are  the  primary  opportunity  for  a  project  office  to  present 
project  resource  requirements  for  inclusion  into  this  approved  planning  document  (C9  and  D77). 

c.  National  security  policy,  as  documented  in  the  draft  DPG  (A1),  provides  guidance  to  the 
Senrices  for  POM  development  around  August  in  the  odd-nurr4>ered  years.  The  final  DPG  should  arrive 
in  November  or  December.  This  provides  the  Secretary  of  Defense  (SECDEF)  fiscally-constrained 
guidance  on  policy,  strategy,  force  planning,  and  resource  planning.  During  this  same  time  frame,  OSD 
provides  the  POM  documentation  requirements,  the  POM  Preparation  Instructions  (PPI)  to  the  Services. 
Based  on  this  information,  all  Major  Commands,  Field  Operating  Agencies,  and  Direct  Reporting  Units 
provide  POM  inputs  to  the  Air  Staff.  The  subsequent  Air  Staff  activities  are  the  subject  of  this  element. 

d.  The  current  structure  for  the  Air  Force  corporate  review/screening  process  was  established  in 
1991 ,  with  the  creation  of  eight  Resource  Allocation  Teams  (RATs).  The  RATs  are  the  focal  points  for 
resource  issues  for  the  following  functional  areas:  Nuclear  Deterrence,  Power  Projection,  Global 
Mobility,  Spa^  and  CCCI,  Materiel  Support,  Personnel  Support,  Classified  Programs,  and  National 
Foreign  Intelligence  Programs.  The  HQ  USAF  Directorate  of  Programs  and  Evaluation  (AF/PE)  is  the 
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office  of  primary  responsibility  for  the  Resource  Allocation  Process.  Another  key  player  in  the  POM 
process  is  the  Pro^am  Element  Monitor  (PEM),  who  is  the  overall  Air  Staff  focal  point  for  the  projects 
within  his  Program  Element  -  the  PEM  is  responsible  for  adc^essing  aH  issues  concerning  his  proj^s.  In 
short,  since  every  Program  Element  (PE)  is  assigned  fo  a  RAT.  the  PEM  must  interface  with  that  team  to 
ensure  his  PE  is  properly  supported. 

e.  In  the  fall  of  the  odd-numbered  years,  the  Major  Commands  provide  their  POM  proposals  to 
HQ  USAF.  These  include  a  prioritized  list  of  disconnects  and  any  *new  starts'  that  are  proposed.  The 
RATs  convene,  and,  with  the  support  of  the  functional  staffs,  SAF/FM  and  AF/PE,  the  teams  review  and 
evaluate  the  Major  Command  inputs.  Based  on  the  POM  inputs,  the  RATs  generate  project  options  for 
presentation  to  the  Air  Force  Council,  CSAF,  and  SECAF  from  late  January  until  early  March  (of  the 
even-numbered  years).  During  this  same  period,  the  participants  update  the  POMs  to  reflect  any 
Congressionai  budget  activities,  the  President's  Budget  submission  to  Congress.  OSD  budget  exercises 
or  fiscal  guidance,  and  new  OSD  Defense  Planning  Guidance  (At)  or  Air  Force  Planning  Guidance  (B1). 

f.  At  the  completion  of  the  POM  deliberations,  SAF/FM  verifies  the  pricing  of  the  approved 
options,  and  the  final  Air  Force  POM  is  documented  and  coordinated.  The  POM  is  submitted  to  OSD  on 
1  April  of  even  numbered  years  (A4).  At  this  time,  SAF/FM  updates  the  FYDP  to  reflect  the  Air  Force 
approved  positions.  At  the  OSD  level,  any  SECDEF  decisions  to  adjust  the  service  POMs  are  recorded 
in  Program  Decision  Memorandums  (PDMs). 

g.  While  OSD  is  holding  the  Program  Reviews,  the  Air  Force  conducts  a  Summer  Review, 
which  consists  of  an  evaluation  of  the  pricing  and  execution  of  the  Air  Force  investment  accounts 
(research  arxJ  development,  procurement,  atxf  military  construction).  Program  and  financial  information 
from  this  review,  plus  any  PDMs  issued  by  OSD,  and  any  necessary  repricing  of  elements  in  the 
databases,  are  used  to  develop  the  Air  Force  BES,  which  is  submitted  to  OSD.  After  OSD  receipt  of  the 
Services'  BES  packages,  a  joint  Assistant  Secretary  of  Defense  (Comptroller)/  Office  of  Management 
and  Budget  (0MB)  Budget  Review  is  conducted  to  ensure  the  prefects  and  dollars  are  correctly  matched. 
The  final  decisions  are  documented  in  Program  Budget  Decisions  (PBDs)  and  Defense  Management 
Report  Decisions  (DMRDs).  The  Sen/ices  are  allowed  a  final  opportunity  to  take  exception  to  the 
PBDs/DMRDs  in  the  Major  Budget  Issues  cycle,  and  then  the  DEPSECDEF  signs  the  final 
PBDs/DMRDs.  This  process  should  be  complete  in  December,  with  the  submission  of  the  Defense 
Budget  to  0MB. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  POM  activities  in  the  field  start  in  the  spring  of  the  odd-numbered  years,  when 
the  Secretariat/Air  Staff  provides  each  Major  Command  with  the  dollar  and  resource  baselines  each 
should  use  to  derive  the  Command's  POM  packages.  In  the  summer,  AF/PE  publishes  the  POM 
Preparation  Instructions,  which  outlines  detailed  instructions  and  submission  schedules.  In  the  fall,  the 
Command  POM  inputs  are  submitted  to  HQ  USAF.  As  for  the  BES,  SAF/PMB  issues  instmetions  that 
usually  result  in  a  so-called  Summer  Review.  That  forms  the  basis  for  the  BES. 

b.  Exit:  The  POM  activity  is  completed  with  the  delivery  of  the  Air  Force  POM  (in  both  hard 
copy  and  computer  file)  to  OSD  at  the  first  of  April  in  the  even-nurr4>ered  years.  The  AF  BES  is 
completed  with  submission  to  OSD  in  September. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  necessary  information  is  cor.lained  in  the  Defense  Planning  Guidance.  Air  Force 
Planning  Guidance,  the  FYDP  arid  the  Major  Command  POM  baselines,  and  the  POM  Planning 
Instructions  (A1,  B1,  C9,  and  D77). 

b.  Outputs;  The  output  is  the  delivery  of  the  Air  Force  approved  documentation  to  OSD. 


10.  KEY  REFERENCES: 
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a.  DoDI  7045.7,  Impiementation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 
23  May  1984.  Describes  procedures  for  OSD  budget  process. 

b.  AFP  172-4,  The  Air  Force  Budget  Process,  Oct  87.  Describes  the  Air  Force  budget  process 

11.  IMPLEMENTATION  TOOLS:  "The  PPBS  Primer,"  7th  Edition,  Jan  93.  This  document,  «vhile  still 
"draft",  is  published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and 
provides  a  valuable  description  of  the  current  PPBS  process.  This  is  one  of  the  few  documents  that 
describes  the  current  process,  and  it  does  so  in  detail.  Further,  it  defir^  the  activity  schedule  for  the 
development  of  the  FY96  POM. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  After  receipt  of  the  Major  Command  POM  inputs  in  the  fall.  Air  Force  works 
POM  Iterations  through  the  following  March.  The  BES  activities  occur  from  August  through  mid- 
September,  when  the  approved  documentation  is  delivered  to  OSD. 

b.  CONSTRAINTS:  The  primary  constraints  to  this  activity  are  the  resource  limitations  placed 
on  the  Air  Force  by  OSD,  aixf  the  schedule  limitations  on  management  reviews  inherent  in  the  budget 
timetable.  A  secorxf  constraint  is  limited  data  (being  pre-Milestone  0)  from  which  to  submit  an  input  that 
could  cover  the  next  8  years.  Yet  if  an  input  is  not  made,  there  may  not  be  adequate  funding  in  the 
future  if  a  project  does  proceed. 

c.  RESOURCES:  The  POM  deliberations  in  the  Air  Staff  require  intensive  activity  by  the 
Resource  Allocation  Teams,  AF/PE,  SAF/FM,  and  the  functional  staffs  to  reconcile  planning  objectives 
and  resources.  The  BES  generation  is  also  a  major  exercise,  but  is  more  limited,  since  it  represents  a 
financial  repackaging  of  the  approved  Air  Force  program. 

d.  LESSONS  LEARNED:  During  the  Air  Staff  POM  deliberations  and  reviews,  it  is  important 
that  the  project  managers  keep  in  close  contact  with  Major  Command  and  the  project  representative(s)  in 
AF/XO  (and  SAF/AQ,  if  someone  has  been  identified).  This  is  important  to  help  resolve  issues  that  may 
arise,  and  to  ensure  that  they  fully  urKferstand  all  the  pertinent  aspects  of  the  project,  arxl  can  deferxl  the 
projected  resource  requirements.  Also,  development  of  the  POM  is  a  comprehensive  and  complex  task, 
and  the  information  requested  can  be  expected  to  change  with  every  submission.  Therefore,  the  POM 
preparer  in  the  project  office  needs  to  ensure  that  (s)he  is  not  only  in  compliance  with  the  formal  tasking 
and  the  local  budget  staff  instructions,  but  also  satisfies  the  information  and  documentation  needs  of  the 
Air  Staff  project  representative. 

e.  BEST  PRACTICES:  After  submission  of  the  POM  package,  the  project  office  should  posture 
itself  to  be  able  to  respond  effectively  to  programmatic  questions,  and  to  be  able  to  generate  quantitative 
answers  to  Air  Staff  requests  to  develop  and  price  out  program  variations  to  the  POM  submission.  The 
capability  to  generate  this  "what-if"  information  in  a  timely  (and  quality)  manner  is  important,  since  the 
reconciliations  and  rankings  to  be  performed  by  the  Resource  Allocation  Teams  may  require 
modifications  to  the  Major  CommarKl  POM  requests  programs  in  terms  of  furxling  levels,  quantities, 
schedules,  or  other  programmatic  aspects.  If  a  project  office  is  unable  to  provide  the  necessary 
information,  or  not  in  time  to  support  the  decision  makers,  the  project  may  not  supported,  or  approved 
with  insufficient  funding  levels. 

f.  TRAPS:  If  the  POM  is  the  first  for  the  project,  the  submission  will  be  considered  a  "New 
Start,"  and  identified  as  such.  There  may  be  additional  documentation  requirements  and  a  higher  level 
of  review  for  these  projects,  since  there  is  not  an  existing  funding  line.  Due  to  this,  the  PEM,  with  project 
office  support,  must  be  especially  prepared  to  defend  potential  future  funding  requirements. 
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1.  ELEMENT:  B6.  TBS  0.2.2.1  (IFC  93-3) 

2.  ELEMENT  TITLE:  Approve  MNS  Threat  (USAF/IN) 

3.  ELEMENT  OWNER(S):  AF/IN 

4.  ELEMENT  STAKEHOLOER(S):  AFISA/INA,  HQ  USAF/INX.  AFIC,  HQ  USAF/ICO,  Product  Center 
Director  of  Intelligence  (Dl),  DIA/DTI-AC.  SAF/AQX,  HQ  USAF/XOR,  and  Operating  Command. 
Implementing  Command. 

5.  REQUIREMENT: 

a.  DoD  Directive  5000.1 .  Defense  Acquisition,  23  Feb  91 .  Part  1 .  This  regulation  addresses 
identifying  and  processing  mission  needs. 

b.  DoD  Instruction  5000.2,  Defense  Acqusition  Management  Policies  and  Procedures,  23  Feb 
91 .  Part  4.  This  regulation  contains  policies  and  procedures  for  production,  review,  and  validation  of 
intelligence  information  support. 

c.  AF  Regulation  200-13,  Intelligence  Support  to  the  Requirements  and  Acquisition  Processes. 
20  Jul  92.  This  regulation  states  the  Air  Force  policy  for  identifying  and  acquiring  intelligence  to  support 
the  Air  Force  requirements  and  acquisition  processes. 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose:  To  review  all  Mission  Need  Statements  (MNS)  to  ensure  consistency  with 
^  intelligence  estimates  and  the  intelligence  infrastructure  base. 

b.  Objective:  To  ensure  the  threat  used  to  support  the  MNS  is  valid  and  approved. 

7.  DESCRIPTION: 

a.  Prior  to  Milestone  0,  the  intelligence  office  of  the  Operating  Command  conducts  a  strategy- 
to-task  analysis  to  determine  whether  the  existing  intelligence  infrastructure  is  sufficient  to  meet  the 
given  need.  Intelligence  infrastructure  components  include  data  flow  and  data  bases;  target  materials; 
mapping,  charting  and  geodesy;  system  interfaces;  security  classification;  and  personnel  and  training. 
The  Operating  Ojmmand's  Intelligence  Counterpart  Officer  (ICO),  in  concert  with  Air  Force  Intelligence 
Command  and  the  Operating  and  Implementing  Commands'  Requirements  staffs,  determines  the 
operational  tasks  associated  with  a  mission  need.  Linking  operational  tasks  to  required  intelligence 
subfunctions  and,  in  turn,  intefligence  programs,  the  ICO  determines  the  infrastructure  requirements  and 
shortfalls  for  a  given  need.  At  the  Air  Staff,  the  HQ  USAF  ICO.  assigned  by  HQ  USAF/INX,  reviews  the 
MNS  (Cl  2)  and  validates  the  intelligence  infrastructure  base  for  a  given  need,  based  on  the  strategy-to- 
task  analysis  (B7). 

b.  Prior  to  an  AF  Systems  Acquisition  Review  Council  (AFSARC),  a  concise,  issue-oriented 
memorandum  is  prepared  by  HQ  AFISA  for  HQ  USAF/IN  signature.  The  memorandum  is  provided  to 
the  AFSARC  Secretary  and  SAF/AQ  staff  at  least  5  days  prior  to  the  AFSARC.  It  is  distributed  to 
AFSARC  principals  to  address  significant  threat  issues  and  to  represent  the  HO  USAF/IN  posKion 
regarding  threat  to  the  project  (B9). 

c.  The  Defense  Intelligence  Agency  (DIA)  further  validates  the  threat  in  the  MNS  and  prepares 
the  intelligence  report  in  support  of  each  D^ense  Acquisition  Board  (DAB)  Milestone  Decision  Review 
(A5). 
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8.  ENTRANCE/EXIT  CRITERIA 

a.  Entrance:  The  critena  lor  starting  this  element  is  the  completion  of  C12.  The  threat  to  be 
countered,  contained  in  the  MNS,  will  be  approved  by  HQ  USAF/IN. 

b.  Exit:  The  exit  criteria  is  HQ  USAF/IN  approval  of  the  threat  content  in  the  MNS. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  threat  analyses  contained  in  the  MNS  which  discusses  the  threat  to  be  countered 
as  well  as  the  projected  threat  environment  is  the  key  input. 

b.  Outputs:  The  key  outputs  are  a  valid  and  approved  threat  section  of  the  MNS  and  the 
memorandum  prepared  for  the  AFSARC. 

10.  KEY  REFERENCES: 

a.  AF  Instruction  10-601,  Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,  16  Feb  93,  Paragraph  1 .1 .7.  This  regulation  contains  information  on  threat  assessment. 

b.  DIA  Regulation  55-3,  Intelligence  Support  for  Defense  Acquisition  Programs,  30  Mar  92, 
Paragraph  10.  This  regulation  contains  guidance  for  threat  preparation. 

11.  IMPLEMENTATION  TOOLS:  The  Air  Force  uses  threat  models  and  scenarios  identified  by  the 
Directors  of  Intelligence  (DIs)  as  potential  candidates  for  validation  as  standard  threat  evaluation  tools. 
HQ  AFMC/IN  maintains  an  intelligence  data  base  to  support  local  AFMC  requirements  and  informs  local 
users  of  new  intelligence  that  may  apply  to  their  programs. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  memorandum  prepared  by  AFISA/INA  is  typically  two  pages  long  and 
takes  several  days  to  prepare.  It  is  coordinated  with  the  intelligence  staffs  of  the  Operating  and 
Implementing  Commands  which  takes  approximately  2  to  3  weeks.  The  memorandum  is  provided  to  the 
AFSARC  Secretary  and  SAF/AQ  staff  at  least  5  days  prior  to  the  AFSARC. 

b.  CONSTRAINTS: 

(1)  Restrictions  regarding  existing  intelligence  infrastructure  support  that  may  have  an 
impact  on  satisfying  the  need. 

(2)  Limitations  on  the  availability  of  data  flow  and  data  bases. 

(3)  Limitations  on  the  availability  of  project  staff. 

(4)  Restrictions  on  time  and  money  needed  to  get  the  job  done. 

(5)  Restrictions  on  availability  of  equipment  and  facilities  needed  to  perform  required 

tasks. 

c.  RESOURCES: 

(1)  ARSA  receives  the  MNS  arxl  writes  the  memorandum.  They  use  two  to  three 
project  teams  for  threat  support.  For  example,  AFISA/INAA  is  presently  divided  into  two  teams.  One  for 
Sp^e  and  Electronic  Conibat  Systems  and  one  for  Weapons  and  Aircraft.  Out  of  those  teams,  one 
threat  support  program  manager  handles  three  to  four  specific  programs  with  back  up  personnel  as 
needed. 

(2)  An  action  officer  from  the  project  team  should  be  appointed  to  interface  with  the  Air 
Force  Intelligence  community  through  the  Product  Center  Dl.  This  is  not  a  full  time  assignment. 
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d.  LESSONS  LEARNED: 

(1 )  Early  and  continued  collaboration  among  the  intelligence  commun^y  and  the 
Operatirtg  and  Irnplementing  Commands  will  expedite  the  development,  review,  approval,  and  validation 
ol  threat  documentation  and  help  to  ensure  the  availability  ol  valid  threat  inlormation  in  a  timely  manner. 

(2)  The  project  team  should  allocate  resources  to  the  intelligence  producer  as  necessary 
throughout  the  acquisition  process. 

(3)  The  iormation  ol  a  Threat  Working  Group  (TWG)  is  an  eHective  means  of  providing 
threat  support  to  any  project.  It  gives  advice,  guidance,  and  recommendations  to  the  project  team  on 
effective  responses  to  the  threat  environment.  The  TWG  should  include  representatives  from  the  project 
office,  the  using  commands,  and  the  appropriate  Director  of  Intelligence  (Dl).  Normally,  this  group  is  not 
formed  until  after  MS  0.  However,  starting  this  group  early  should  be  considered.  Early  involvement 
establishes  clear  lines  of  communication  and  aids  the  project  team  in  acquiring  timely  threat  information. 

e.  BEST  PRACTICES: 

(1 )  The  project  team  should  participate  with  the  intelligence  community  in  the 
development  and  implementation  of  long-range  forecasting  methodologies  and  threat  integration 
techniques.  The  Product  Center  (Dl)  (ASC/NAIC/TIA,  DSN  785-4285,  lor  ASC)  is  a  good  starting  point. 

(2)  For  additional  inlormation  concerning  HQ/IN  threat  approval,  HQ  AFISA/INAA,  DSN 
225-7577, 1700  Air  Force  Pentagon,  Washington,  DC  20330-1700. 

f.  TRAPS:  Failure  to  maintain  consistency  when  producing  the  various  threat  documents  for  a 
particular  program  will  lead  to  misunderstanding  and  confusion. 
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1.  ELEMENT:  B7.  TBS  0.2.2.3  (IFC  93-3) 

2.  ELEMENT  TITLE:  Staff  and  Coordinate  MNS  (Air  Staff) 

3.  ELEMENT  OWNER:  AF/XOR 

4.  ELEMENT  STAKEHOLDER(S):  Operating  Command.  AFMC,  AFOTEC,  Participating  Commands, 
and  AF/XOR  staff. 

5.  REQUIREMENT:  AFPD  10-6,  Mission  Needs  and  Operational  Requirements.  19  Jan  93.  Attachment 

3.  kjentifies  Mission  Need  Statement  (MNS)  approval  requirements.  AF1 10-601 .  Mission  Needs  and 
Operaliortal  Requiremertts  Guidance  and  Procures.  16  Feb  93,  Attachment  4.  identifies  MNS  staffing 
and  coordinalion  procedures. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Staff  and  coordinate  the  Mission  Need  Statement  (MNS)  at  the  Air  Staff. 

b.  Objective:  Obtain  Air  Force  Chief  of  Staff  (CSAF)  approval. 

7.  DESCRIPTION:  The  overall  MNS  staffing  and  coordination  process  begins  at  the  operating 
command  where  the  MNS  is  drafted  (Cl 2).  continues  with  Air  Staff  coordinalion  (B7).  JROC  Service. 
CINC.  and  Joint  Staff  coordination  (ACAT  I)  (A6).  and  ends  with  either  CSAF  approval  (ACAT  ll-IV)  or 
validation  and  approval  by  the  JROC  (ACAT  I)  (M).  The  Air  Staff  and  JROC  will  use  the  latest  threat 
information  to  ensure  the  threat  used  to  devel^  the  MNS  is  valid  (B6  and  AS.  respectively).  The  JROC 
also  will  review  ACAT  I  MNS  for  assignment  of  joint  potential  designator  (i.e..  potential  for  joint 
applicability).  For  ACAT  ll-IV  MNS.  validation  and  approval  are  done  by  the  Air  Force  with  the  Operating 
Command  as  the  validation  authority  and  CSAF  as  the  approval  authority  (JROC  assistance  may  be 
requested  to  resolve  lead  Service  issues).  This  data  sheet  addresses  the  Air  Staff  portion  of  the  MNS 
staffing  and  coordination  process. 

(Note:  This  data  sheet  assumes  a  single  Operating  Command  is  the  need  originator.  An  Air  Force 
MNS  can  also  originate  from  other  sources,  including  CINCs,  the  Joint  Staff,  HQ  USAF,  unified  or 
specified  commands,  or  other  Federal  Agencies  (i.e.,  FAA  or  NASA).  See  AF1 10-601 ,  paragraph  1 .3, 
for  more  information.) 

The  Air  Staff  focal  point  for  MNS  staffing  and  coordination  is  AF/XOR.  AF/XOR  receives  the  draft 
*for  comment*  MNS  prior  to  Operating  Command  final  approval.  AF/XOR  distributes  the  draft  'for 
comment*  MNS  to  appropriate  Air  Staff  and  Secretariat  offices,  collects  comments,  and  returns  them  to 
the  Operating  Comrrumd  OPR  for  incorporation.  For  ACAT  I  programs,  AF/XOR  concurrently  submits 
the  for  comment*  MNS  to  the  JROC  Secretariat  for  Colonel-level  Service,  CINC,  and  Joint  Staff  review. 

After  Operating  Command  validation,  the  MNS  is  ready  for  the  final  'coordination*  phase.  The  MNS 
is  sent  to  AF/XOR  for  final  Air  Staff  coordination,  then  CSAF  approval.  For  ACAT  I  programs,  AF/XOR 
concurrently  submits  the  final  MNS  to  the  JROC  Secretariat  for  2-star  level  Service.  CINC.  and  Joint 
Staff  review. 

An  assessment  of  Joint  Service  potential,  or  harmonization,  is  part  of  the  validation  process.  All 
MNS  are  forwarded  to  the  other  Senrices  for  an  assessment  of  Joint  potential.  AF/XOR  ensures  a  Joint 
Potential  Designator  (JPD)  is  assigned  to  each  MNS,  to  descrtt>e  the  expected  level  of  Joint  Senrice 
involvement.  A  MNS  will  be  classified  as  either  Independent  (no  involvement).  Joint  Interest  (potential 
use  or  interface  by  another  Service),  or  Joint  (potential  for  Joint  program  management). 
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FoMowing  CSAF  approval,  the  MNS  is  forwarded  to  the  JROC  (ACAT I)  or  the  Milestone  Decision 
Authority  (MDA)  (ACAT  ll-IV)  (B9). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  When  AF/XOR  receives  the  lor  comment'  MNS  from  the  operating  command. 

b.  Exit:  When  the  MNS  is  approved  by  CSAF. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  lor  comment*  MNS  from  the  operating  command  (Cl  3).  Current  threat  information 
from  AF/IN  (B6),  validated  by  DIA  (ACAT  I)  (AS),  to  ensure  the  threat  used  to  develop  the  MNS  wiN 
remain  valid  up  to  CSAF  approval. 

b.  Outputs:  A  CSAF  approved  MNS  that  is  forwarded  to  the  JROC  (ACAT  I),  or  notification  to  the 
MDA  that  the  MNS  has  been  approved  or  disapproved  (ACAT  ll-IV). 

10.  KEY  REFERENCES:  See  Requirement,  paragraph  5. 

11.  IMPLEMENTATION  TOOLS:  None  identHied. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Typical  (optimistic)  staffing  and  coordination  schedule  for  Air  Staff: 

Draft  for  comment*  phase: 

45  days  (review) 

15  days  (operating  MAXOM  work  comments) 

Final  'coordination*  phase: 

45  days  (coordination  and  CSAF  approval) 

Note:  Entire  process  (from  Air  Staff  receipt  of  draft  MNS,  through  MAJCOM  working  comments,  to 
CSAF  approval)  could  take  several  months. 

b.  CONSTRAINTS:  None  identified. 

c.  RESOURCES:  An  OPR  will  be  required  at  AF/XOR  (maybe  more  than  one  depending  on  size 
and  visfoility  of  the  program)  to  conduct  the  staffing  and  coordination  process.  The  AF/XOR  OPR  may 
be  handling  between  1 0  and  40  MNS  at  a  time.  An  OPR  will  be  required  from  each  Air  Staff  organization 
receiving  the  MNS  from  AF/XOR  for  comment  and  coordination. 

d.  LESSONS  LEARNED:  This  activity  is  handled  by  the  AF/XOR  OPR  and  the  operatii^  MAJCOM 
OPR.  Product  Center  involvement  normally  would  have  occurred  prior  to  staffing  and  coordination, 
hopefully  in  support  of  the  mission  need  analysis  and  development  of  the  MNS.  If  major  issues  arise 
during  this  activity,  however,  the  operating  MAJCOM  OPR  and  AF/XOR  should  notify  major  stakeholders 
(i.e.,  Product  Center)  and  plan  for  resolution  as  a  team. 

Reviewers  should  take  the  time  to  ensure  the  MNS  is  a  quality  document:  (1 )  Pay  special  attention 
to  whether  the  MNS  is  properly  focused  on  needs,  not  solutions.  (2)  Confirm  that  the  need  is  real,  relates 
to  Defense  Planning  Guidance,  and  is  based  on  the  current  foreat.  (3)  Challenge  system  specific 
requirements  or  unsubstantiated  required  capability  dates.  (4)  Ensure  all  constraints  have  been 
identified.  (5)  Ensure  the  MNS  does  not  evaluate  potential  alternatives. 
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Adequate  slack  time  should  be  built  into  the  schedule,  especially  for  potentially  controversial 
programs,  to  ensure  a  quality  review  can  be  done.  With  alt  the  coordination  arKf  working  of  comments, 
there  are  bourxJ  to  be  obstacles  that  ret^ire  extraordinary  effort  to  overcome,  such  as  unforeseen  issues, 
turf  battles,  and  other  differences  of  opinion.  This  is  especially  true  for  Joint  needs. 

e.  BEST  PRACTICES:  The  Product  Center  OPR  should  stand  by  atvl  be  prepared  to  help  the 
operating  MAJCOM  OPR  work  any  comments  received  during  staffing  and  coordination. 

Product  Center  and  operating  MAJCOM  OPRs  should  be  "working  the  party"  (talking  with  important 
Air  Staff  offices  such  as  AF/IN,  SAF/AO,  and  AF/XO)  before  actual  coordination. 

f.  TRAPS:  Not  building  enough  time  into  the  staffing  and  coordination  schedule.  Not  working 
up  front  with  organizations  whose  coordination  is  needed  most. 
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1.  ELEMENT:  B8.  TBS  1.1.1. 5.2  (IFC  93-3) 

2.  ELEMENT  TITLE;  Update  POM/BES  Input 

3.  ELEMENT  OWI«R:  Secretary  of  the  Air  Force  (SECAF) 

4.  ELEMENT  STAKEHOLDER(S):  CSAF.  AF/PE,  SAF/FM.  AF/XO.  Operating  Command.  Project 
Manager,  and  PEO. 

5.  REQUIREMENT:  DoD  Directive  7045.14,  The  Planning,  Programming,  and  Budget  System  (PPBS), 
22  May  1964.  Describes  OSD  budget  process. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  To  ensure  that  all  funding  is  available  to  support  execution  of  the  planned  project. 
Initial  Program  Objective  Memorandum  (POM)  wedges  should  be  submitted  or  updated  at  the  earliest 
opportunity. 

b.  Objectives.  To  prevent  possible  schedule  delays  later  due  to  inadequate  funding. 

7.  DESCRIPTION: 

a.  The  development  of  the  Air  Force  Program  Objective  Memorandum  (POM)  is  the  process  by 
which  all  resources  required  to  execute  OSD  Defense  Planning  Guidance  (DPG)  are  documented  and 
validated.  The  POM  is  used  to  update  the  planning  for  the  6  years  contained  in  the  Future  Year  Defense 
Program  (FYDP).  After  OSD  adjustments  are  made  to  the  POM,  the  Air  Force  is  allowed  to  update  and 
reprice  the  projects  which  were  approved  .  This  is  documented  in  the  Budget  Estimate  Submission 
(BES),  which  emphasizes  the  first  2  years  of  the  FYDP,  and  converts  the  project  oriented  format  of  the 
POM  into  the  appropriation  categories.  At  this  phase  of  an  acquisition,  the  project  may  not  need  much 
funding,  but  if  the  project  could  require  funding  during  any  of  the  years  included  in  the  POM,  it  is 
essential  to  submit  a  POM  input. 

b.  The  FYDP  is  the  official  DoD  data  base  and  document  which  is  a  compilation  of  the  total 
resources  (forces,  manpower,  and  dollars)  programmed  for  DoD,  arranged  by  Major  Force  Program 
(MFP)  and  appropriation.  The  FYDP  projects  6  years  for  all  data  except  forces,  which  extend  an 
additional  3  years.  The  POM  submissions  are  the  primary  opportunity  for  a  project  office  to  present 
project  resource  requirements  for  inclusion  into  this  approved  planning  document  (D20A,  C14,  and  C15). 

c.  National  security  policy,  as  documented  in  the  draft  DPG  (A1),  provides  guidance  to  the 
Services  for  POM  development  around  August  in  the  odd-numbered  years.  The  final  DPG  should  arrive 
in  November  or  December.  This  provides  the  Secretary  of  Defense's  (SECDEF’s)  fiscally-constrained 
guidance  on  policy,  strategy,  force  planning,  aixf  resource  planning.  During  this  same  time  frame,  OSD 
provides  the  POM  documentation  requirements,  the  POM  Preparation  Instructions  (PPI),  to  the  Services. 
Based  on  ths  information,  all  Operating  Commands,  Field  Operating  Agencies,  and  Direct  Reporting 
Units  provide  POM  inputs  to  the  Air  Staff.  The  subsequent  Air  Staff  activities  are  the  subject  of  this 
element. 

d.  The  current  structure  for  the  Air  Force  corporate  review/screening  process  was  established  in 
1991 ,  with  the  creation  of  eight  Resource  Allocation  Teams  (RATs).  The  RATs  are  the  focal  points  for 
resource  issues  for  the  following  functional  areas;  Nuclear  Deterrence,  Power  Projection,  Global 
Mobility,  Space  and  CCCI,  Materiel  Support,  Personnel  Support.  Classified  Programs,  and  National 
Foreign  Intelligence  Programs.  The  HQ  USAF  Directorate  of  Programs  and  Evaluation  (AF/PE)  is  the 
office  of  primary  responsibility  for  the  Resource  Allocation  Process.  Another  key  player  in  the  POM 
process  is  the  Program  Element  Monitor  (PEM),  who  is  the  overall  Air  Staff  focal  point  for  the  projects 
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within  his  Program  Element  -  the  PEM  is  responsible  for  addressing  all  issues  concerning  his  projects.  In 
short,  since  every  Program  Element  (PE)  is  assigned  to  a  RAT,  the  PEM  must  interlace  with  that  team  to 
ensure  his  PE  is  properly  supported. 

e.  In  the  fall  of  the  odd-numbered  years,  the  Operatirrg  Commands  provide  their  POM  proposals 
to  HQ  USAF.  These  include  a  prioritized  Kst  of  disconnects  and  any  ‘new  starts'  that  are  proposed.  The 
RATs  convene,  and,  with  the  support  of  the  functional  staffs.  SAF/FM  and  AF/PE,  the  teams  review  and 
evaluate  the  Gyrating  Command  inputs.  Based  on  the  POM  inputs,  the  RATs  generate  project  options 
tor  presentation  to  the  Air  Force  Council,  CSAF,  and  SECAF  from  late  January  until  early  March  (of  the 
even-numbered  years).  During  this  same  period,  the  participarrts  update  the  POMs  to  reflect  any 
Congressional  budget  activities,  the  President's  Budget  submission  to  Congress,  OSD  budget  exercises 
or  fiscal  guidance,  and  new  OSD  Defense  Planning  Guidance  (A1)  or  Air  Force  Planning  Guidance  (B1). 

f.  At  the  completion  of  the  POM  deliberations,  SAF/FM  verifies  the  pricing  of  the  approved 
options,  and  the  final  Air  Force  POM  is  documented  and  coordinated.  The  POM  is  submitted  to  OSD  on 
1  /Vpril  of  even  numbered  years  (A7).  At  this  time,  SAF/FM  updates  the  FYDP  to  reflect  the  Air  Force 
approved  positions.  At  the  OSD  level,  any  SECDEF  decisions  to  adjust  the  Sen/ice  POMs  are  recorded 
in  Program  Decision  Memorandums  (PDMs). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  POM  activities  in  the  field  start  in  the  spring  of  the  odd-numbered  years,  when 
the  Secretariat/ Air  Staff  provides  each  Operating  Command  with  the  dollar  and  resource  baselines  each 
should  use  to  derive  the  Operating  Command  POM  packages.  In  the  summer,  AF/PE  publishes  the 
POM  Preparation  Instructions,  which  outlines  detailed  instructions  and  submission  schedules.  In  the  fall, 
the  Operating  Command  POM  inputs  are  submitted  to  HQ  USAF. 

b.  Exit;  The  activity  is  completed  with  the  delivery  of  the  Air  Force  POM  (in  both  hard  copy  and 
computer  file)  to  OSD  at  the  first  of  April  in  the  even-numbered  years. 

9.  KEY  INPUTS  AND  OUTPUTS; 

a.  Ir^ts;  The  necessary  information  is  contained  in  the  Defense  Planning  Guidance,  Air  Force 
Planning  Gui^nce,  the  FYDP  and  the  Operating  Command  POM  baselines,  and  the  POM  Planning 
Instnjctions  (D20A,  Cl  4,  C15,  A1,  and  B1). 

b.  Outputs;  The  output  is  the  delivery  of  the  Air  Force  approved  documentation  to  OSD. 

10.  KEY  REFERENCES: 

DoDI  7045.7,  Implementation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 

23  May  1984.  Describes  procedures  for  OSD  budget  process. 

AFP  172-4,  The  Air  Force  Budget  Process,  Oct  87. 

11.  IMPLEMENTATION  TOOLS:  The  PPBS  Primer,"  7th  Edition,  Jan  93.  This  document,  while  still 
"draft,"  is  published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and 
provides  a  valuable  description  of  the  current  PPBS  process.  This  is  ore  of  the  few  documents  that 
describes  the  current  process,  and  it  does  so  in  detail.  Further,  it  defines  the  activity  schedule  for  the 
development  of  the  FY96  POM. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  After  receipt  of  the  Operating  Command  POM  inputs  in  the  fall.  Air  Force  works 
POM  iterations  through  the  following  March. 


b.  CONSTRAINTS:  The  primary  constraints  to  this  activity  are  the  resource  limitations  placed 
on  the  Air  Force  by  OSD,  and  the  schedule  limitations  on  management  reviews  inherent  in  the  budget 
timetable.  A  second  constraint  is  limited  data  (being  pre-Milestone  0)  from  which  to  submit  an  input  that 
could  cover  the  next  8  years.  Yet  if  an  input  is  not  made,  there  may  rxM  be  adequate  funding  in  tlw 
future  if  a  project  does  proceed. 

c.  RESOURCES:  The  POM  deliberations  in  the  Air  Staff  require  intensive  activity  by  the 
Resource  Allocation  Teams,  AF/PE,  SAF/FM,  and  the  functional  staffs  to  reconcile  planning  objectives 
and  resources. 

d.  LESSONS  LEARNED:  During  the  Air  Staff  POM  deliberations  and  reviews,  it  is  important 
that  the  project  managers  keep  in  close  contact  with  Operating  Command  and  the  project 
representative(s)  in  AF/XO  (and  AF/AQ,  if  someone  has  been  identified).  This  is  important  to  help 
resolve  issues  that  may  arise,  artd  to  ensure  that  they  fully  understand  all  the  pertinent  aspects  of  the 
project,  and  can  defend  the  projected  resource  requirements.  Also,  development  of  the  POM  is  a 
comprehensive  and  complex  task,  and  the  information  requested  can  be  expected  to  change  with  every 
submission.  Therefore,  the  POM  preparer  in  the  project  office  needs  to  ensure  that  (s)he  is  not  only  in 
compliance  with  the  formal  tasking  and  the  local  ^dget  staff  instructions,  but  also  satisfies  the 
information  and  documentation  needs  of  the  Air  Staff  project  representative. 

e.  BEST  PRACTICES:  After  submission  of  the  POM  package,  the  project  office  should  posture 
itself  to  be  able  to  respond  effectively  to  programmatic  questions,  and  to  be  able  to  generate  quantitative 
answers  to  Air  Staff  requests  to  develop  and  price  out  program  variations  to  the  POM  submission.  The 
capability  to  generate  this  "what-if  information  in  a  timely  (and  quality)  manner  is  important,  since  the 
reconciliations  and  rankings  to  be  performed  by  the  Resource  Allocation  Teams  may  require 
modifications  to  the  Operating  Command  POM  requests  programs  in  terms  of  funding  levels,  quantities, 
schedules,  or  other  programmatic  aspects.  If  a  project  office  is  unable  to  provide  the  necessary 
information,  or  not  in  time  to  support  the  decision  makers,  the  project  may  not  be  supported,  or  approved 
with  insufficient  funding  levels. 

f.  TRAPS:  If  the  POM  is  the  first  for  the  project,  the  submission  will  be  considered  a  "New 
Start,"  and  identified  as  such.  There  may  be  additional  documentation  requirements  and  a  higher  level 
of  review  for  these  projects,  since  there  is  not  an  existing  funding  line.  Due  to  this,  the  PEM,  with  project 
office  support,  must  be  especially  prepared  to  defend  potential  future  funding  requirements. 
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1.  ELEMENT:  B9.  TBS  0.2.2.5  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  AFSARC  Review  (Air  Force  Systems  Acquisition  Review  Council) 

3.  ELEMENT  OWNER(S):  Air  Force  Acquisition  Executive  (AFAE) .  SAF/AQX 

4.  ELEMENT  STAKEHOLDER(S):  Operating  MAJCOM,  Air  Force  Acquisition  Executive  (AFAE) . 
SAF/AQX.  and  Implementing  Command. 

5.  REQUIREMENT; 

a.  SAF  Order  No.  20.6  'Establishment  of  the  Department  of  the  Air  Force  Systems  Acquisition 
Review  Council  (AFSARC), *23  Nov  81 .  This  defines  the  Secretary  of  the  Air  Force  (SAF)  directed-roles 
and  responsibilities  of  the  AFSARC. 

b.  SAF/AQ  Memorandum  for  AFSARC  members,  17  Apr  3.  This  covers  who  will  present 
information  to  the  AFSARC. 

c.  DoDl  5000.2,  Part  1 1 ,  Section  C.  This  delineates  the  documents  required  for  milestone  reviews. 

d.  AF  Sup  1/DoDI  5000.2  Part  13  Section  A,  Atch  1,  Aug  92.  This  section  covers  the  basic 
procedures  that  the  AFSARC  will  follow. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  AFSARC  process  implements  DoDI  5000.2  Section  1 1-C  for  the  Air  Force 
Acquisition  Executive  (AFAE)  review  of  ACAT I  programs,  any  Joint  program  for  which  the  Air  Force  is 
the  lead,  and  ACAT  ll-IV  programs  as  determined  by  the  Secretary  of  the  Air  Force  (SAF)  or  AFAE. 

b.  Objective:  The  AFSARC  is  convened  to  review  ACAT  I  acquisition  programs  prior  to  a  milestone 
decision  or  prior  to  a  program  review  by  the  Secretary  of  Defense.  It  is  the  Air  Force  review  process 
which  reviews  all  program  documentation  prior  to  going  to  the  Defense  Acquisition  Board  (DAB).  The 
AFSARC  functions  as  the  DAB  for  all  Air  Force  programs  that  are  less  than  ACAT  I.  The  AFSARC  is 
held  in  addition  to  both  the  Summit  reviews  and  the  DAB  reviews.  All  three  of  these  reviews  essentially 
do  the  same  thing,  they  review  all  the  program  documentation  to  make  a  recommendation  for  or  the 
actual  decision  for  program  go-ahead  or  continuance.  The  only  difference  between  the  three  is  the  level 
of  review  and  the  decision  authority  of  the  participants. 

7.  DESCRIPTION:  This  block  is  the  first  major  Air  Force  Review  of  the  program  prior  to  issuing  an 
Acquisition  Decision  MerTK>rarxkim  (ADM).  It  falls  between  the  Joint  Requirements  Oversight  Council 
(JROC)  and  the  DAB  Predecessor  blocks  are  A-8,  B-7,  C-1 4.  Successor  blocks  are  A-9  and  B-10. 

a.  The  AFSARC  is  the  Air  Force  corporate  body  that  advises  the  AFAE  on  the  acquisition  of  major 
systems.  There  are  1 1  permanent  AFSARC  members  and  3  advisors. 

Chair:  The  AFAE,  who  is  the  Assistant  Secretary  of  the  Air  Force  (Acquisition),  chairs  the 

AFSARC. 

Members:  Assistant  Secretary  of  the  Air  Force  (Financial  Management  and  Comptroller) 

Assistant  Secretary  of  the  Air  Force  (Space) 

Assistant  Secretary  of  the  Air  Force  (Manpower,  Reserve  Affairs,  Installations,  arxl 

Environment) 

Vice  Chief  of  Staff 

Deputy  Chief  of  Staff  (Personnel) 

Deputy  Chief  of  Staff  (Plans  and  Operations) 

Deputy  Chief  of  Staff  (Logistics) 
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Deputy  Chief  of  Staff  (Test  and  Evaluation) 

Director  of  Programs  and  Evaluation 

Commander,  Air  Force  Operational  Test  and  Evaluation  Center 

Commander,  Air  Force  Test  and  Evaluation 

Advisors:  General  Counsel 

Assistant  Chief  of  Staff  for  Intelligence 
Director  of  Strategic,  SOF  and  Airlift  Programs 

b.  The  AFSARC  also  has  an  Executive  Secretary  responsi>le  for  administrative  support  to  the 
AFSARC.  The  Executive  Secretary  is  responsible  for :  scheduling  AFSARC  meetings  and  pre-briefs, 
publishing  the  AFSARC  planning  schedule,  distributing  read-ahead  material,  publishing  AFSARC 
meeting  ^endas  and  approved  attendance  lists,  guidance  on  AFSARC  policy  and  procedure,  and 
coordinating  Air  Force  participation  in  the  DAB. 

c.  For  definition  purposes,  the  SAF/AQ  or  AF  organization  responsible  for  the  Program  Element 
Monitor  (PEM)  function  is  designated  as  the  ‘Sponsoring  AFSARC  Member.* 

d.  The  AFAE  may  convene  an  AFSARC  for  the  following  reasons:  1)  to  review  acquisition  programs 
prior  to  milestone  decisions  or  prior  to  program  review  by  the  Secretary  of  Defense  or  the  DAB;  2)  to 
review  programs  when  mminated  for  review  by  an  AFSARC  member  and  approved  by  the  AFAE;  3)  as 
requested  by  the  AFAE;  4)  as  directed  by  the  Secretary  of  the  Air  Force.  There  are  three  types  of 
AFSARC  meetings  -  Milestone  Meeting,  Program  Review,  and  Principals  Meeting.  Only  the  Milestone 
Meeting  is  discussed  in  detail  here. 

e.  AFSARC  meetings  are  approved  by  the  AFAE.  Members  and  advisors  are  notified  of  meetings  by 
the  Executive  Secretary.  A  listing  of  all  planned  AFSARCs  »  published  every  4  months. 

f.  Milestorre  AFSARCs  can  only  be  waived  by  the  AFAE.  The  AFAE  is  the  Decision  Authority  for 
special  requirements,  operating  procedures,  and  abbreviation  or  waiver  of  documentation  requirements. 

g.  Procedures.  For  DAB  programs  a  Joint  OSD-AF  meeting  will  be  held  approximately  6  months 
before  the  planned  milestone.  This  will  be  scheduled  by  OSD.  At  this  planning  meeting  the  Project 
Manager  or  PEM  should  present  the  project  status,  a  proposed  project  schedule,  as  much  cost 
information  as  is  available,  the  potential  issues  and  schedule  of  efforts  to  be  accomplished  to  get  to  the 
AFSARC.  Remember  an  Integrated  Program  Summary  (IPS)  and  a  Cost  Analysis  Requirement 
Description  (CARD)  are  not  required  for  a  Milestone  0  DAB,  but  the  infonnation  that  is  in  an  IPS  and 
CARD  is  the  type  of  information  the  decision  makers  want  to  see. 

h.  Attendance.  Only  AFSARC  members  and  advisors  or  their  representatives  are  allowed  to  atterxl 
the  AFSARC.  Other  attendees  are  at  the  written  invitation  of  the  AFAE.  The  sponsoring  AFSARC 
member  will  provide  recommendations  for  other  attendees  to  the  Executive  Secretary  at  least  5  days 
prior  to  the  AFSARC  meeting.  Be  sure  the  PEM  secures  the  approval  for  appropriate  SPO  and  Using 
Command  personnel  attendance. 

8.  ENTRANCBEXIT  CRITERIA: 

a.  Entrance:  Prior  to  an  AFSARC,  all  pertinent  documentation  must  be  prepared.  The  sponsoring 
AFSARC  member  is  responsible  to  ensure  all  required  documentation  and  special  reports  are  submitted 
at  least  6  working  days  before  the  AFSARC. 

For  ACAT I  programs,  the  AFSARC  is  normally  held  at  least  5  weeks  before  the  DAB  review.  Other 
AFSARC  meetings  will  be  held  as  determined  by  the  AFAE.  However,  it  is  the  responsibility  of  the 
sponsoring  member  to  ensure  the  AFSARC  is  scheduled  for  those  programs  that  will  only  require  an 
AFSARC  (non-DAB  programs). 
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b.  Exit:  Exit  from  tNs  block  when  the  decision  is  made  to  go  ahead  to  the  DAB  or  issue  a  go-ahead 
to  proceed  into  Phase  0. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  documentation  requiremerYs  for  an  AFSARC  are  the  same  as  for  a  Milestone  Review. 
For  Milekone  0  the  MNS  and  DIA  Intelligerx^e  Report  (ACAT I)  or  Component  InteHigerK^  Report  (ACAT 
11,111,1V)  are  required.  See  blocks  A-5  Validate  MNS  Threat  (DIA),  B-07  -  Air  Staff  MNS  Staffing  arid 
Coordination;  C14  -  Develop  Draft  Phase  0  Plans  (Lead  MAJCOM). 

b.  Outputs:  The  output  of  an  AFSARC  is  either  an  Acquisition  Decision  Memorandum  (ADM)  for 
non-DAB  programs  or,  for  DAB  programs,  a  memo  that  goes  to  the  DAB  along  with  all  the  other  required 
documentation.  See  blocks  AOS  -  (Conduct  DAB  Milestone  0  Review,  and  BIO  -  Write  and  Issue  Phase  0 
Program  Management  Directive  (PMD).  For  non-DAB  programs,  the  sponsoring  member  will  prepare  an 
Acquisition  Decision  Memorandum  (ADM)  through  the  AFSARC  Executive  Secretary,  for  signature  by 
the  AFAE  within  5  working  days  after  the  AFSARC  review.  For  DAB  programs,  the  sponsoring  member 
will  update  the  briefing  for  the  DAB  to  include  AFSARC  findings,  coordinate  it  within  the  Air  Staff,  and 
provi^  the  results  to  the  DAE  within  1 0  working  days. 


10.  KEY  REFERENCES: 

a.  SAF  Order  No.  20.6  ‘Establishment  of  the  Department  of  the  Air  Force  Systems  Acquisition  * 

Review  Council  (AFSARC), *23  Nov  81 .  This  defines  the  SAF  directed  roles  and  responsibilities  of  the 

AFSARC. 

b.  SAF/AQ  Memorandum  for  AFSARC  members,  17  Apr  93.  This  covers  who  will  present 

information  to  the  AFSARC.  ^ 

c.  OoDI  5000.2,  Part  11,  Section  C.  This  delineates  the  documents  required  for  milestone  reviews. 

d.  AF  Sup  1/DoDI  5000.2  Part  13  Section  A,  Atch  1 ,  Aug  92.  This  section  covers  the  basic 
procedures  that  the  AFSARC  will  follow. 

e.  SAF/AQ  Acquisition  Policy  93M-0XX  (DRAFT)  "Milestone  0  Decision  Process  -  ACTION  • 

MEMORANDUM.’  This  covers  the  roles  and  responsibilKies  of  various  organizations  as  well  as  needs 

and  procedures  for  the  Milestone  0  decision  process. 

11.  IMPLEMENTATION  TOOLS:  AFSARC/DAB  Planning  Guidelines  summarize  the  steps  normally 
required  for  each  milestone.  Contact  SAF/AQX  for  the  current  copy  of  this  document. 

• 

12.  PLANNING  GUIDANCE:  The  AFSARC/DAB  Planning  Quidelines/Checklist  has  the  schedule  of 
events  that  are  required  prior  to  an  AFSARC.  Essentially,  the  process  starts  6  to  7  months  prior  to  a 
DAB  with  an  AFSARC  planning  meeting,  and  has  multiple  meetings  and  reviews  prior  to  the  DAB.  See 
the  AFSARC/DAB  planning  guidelines  for  the  latest  detailed  information. 

a.  DURATION:  The  AFSARC  meeting  itself  is  normally  a  1  day  affair.  However,  it  takes  6  to  7  • 

months  to  get  alt  the  documents  ready  for  the  review. 

b.  CONSTRAINTS:  Major  constraints  for  the  AFSARC  are  getting  the  program  documentation 
ready  in  time  and  in  the  proper  format.  Don't  make  this  a  marketing  briefing;  follow  guidelines  explicitly. 

Another  constraint  is  the  briefing  itself.  This  will  require  numerous  changes  and  practice  briefings. 

Ensure  you  allow  sufficient  time  prior  to  the  actual  AFSARC  meeting  to  get  all  the  pre-briefs  ^ 

accomplished. 
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c.  RESOURCES:  All  functional  disciplines  must  be  involved  in  this  process.  The  number  of 
person-hours  required  is  difficult  to  define  but  will  be  high.  There  are  no  special  security.  facWties, 
computers  (hardware  and/Or  software),  required  specifically  for  the  AFSARC.  The  only  requiremenis  are 
those  required  for  the  normal  program  security. 

d.  LESSONS  LEARNED:  Contact  the  SAF/AQX  office  for  the  latest  guidance  and  lessons  learned 
from  the  most  recent  AFSARC  and  to  get  the  latest  personal  preferences  of  the  AFSARC  members 
about  how  they  want  to  be  briefed.  You  are  briefing  this  panel  to  convince  them  that  the  program  should 
be  funded.  It  is  in  your  best  interest  to  brief  them  in  a  manner  they  like.  Personal  preferences  with 
respect  to  chart  format,  data  presentation  format  and  conduct  of  the  briefing  should  be  coordinated  with 
the  AFSARC  Executive  Secretary  prior  to  putting  together  the  briefing  charts  for  the  AFSARC. 

e.  BEST  PRACTICES:  It  is  a  good  idea  to  pre-brief  the  members  of  the  AFSARC  or  at  least  their 
staffs  before  the  AFSARC  review  to  make  sure  you  are  covering  their  concerns  in  the  AFSARC  briefing. 
This  is  not  always  easy  to  do  but  is  a  good  idea. 

Remember  an  IPS  and  a  CARD  are  not  required  for  a  Milestone  0  DAB.  However,  the  latest 
guidance  from  SAF/AQX  is  that  you  should  have  in  your  'hip  pocket'  an  IPS/CARD  plan  of  attack  even 
for  this  milestone  review. 

f.  TRAPS:  Not  using  the  correct  briefing  format.  Not  submitting  the  required  documentation  early  in 
the  process. 
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1.  ELEMENT:  BIO,  TBS  0.2.3.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Write  and  Issue  Phase  0  PMD 

3.  ELEMENT  OWNER(S):  SAF/AQXA,  AF/XOfl 

4.  ELEMENT  STAKEHOLDER(S):  AF/XOR,  Operating  Command.  Other  SAF/AQ  4  Ltr  Offices.  AF/IN. 
and  implementing  Command. 

5.  REGKHREMENT:  AFR  800-1.  Air  Force  Acquisition  System.  16  Feb  90.  Paragraph  3.a.  DeTmesthe 
requirement  arxj  point  of  contact  for  Program  Management  Directives  (PMDs). 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  the  PMD  is  to  direct  programmatic  responsibilities  to  major 
command,  field,  and  test  organizations  for  systems  development,  modification,  or  acquisition  in  broad 
terms.  PMDs  originate  within  the  Headquarters  (Secretariat  and  Air  Staff)  and  are  coordinated  with  aH 
outside  implementing,  supporting,  participating,  operating,  and  test  agencies. 

b.  Objectives;  The  intent  of  the  PMD  is  to  integrate  all  activities  which  affect  the  life  cycle  of  an 
acquisition.  All  Air  Force  acquisitions  are  required  to  have  a  complete  and  current  PMD. 

7.  DESCRIPTION: 

a.  Once  the  Milestone  Decision  Authority  (MDA)  makes  a  decision  to  proce^  with  Concept 
Exploration  and  Definition  (CE&D).  an  Acquisition  Decision  Memorandum  (ADM)  is  issued  in  accordance 
with  DoDI  5000.2.  Parts  1 1B  and  1 1C  (A9).  For  non-Defense  Acquisition  Board  (DAB)  projects,  the 
sponsoring  memt^  will  prepare  an  ADM  for  Air  Force  Acquisition  Executive  (AFAE)  signature  (B9). 
Upon  receipt  of  the  ADM  from  the  MDA,  the  appropriate  Air  Staff  Office  (e  g..  AF/XOR)  issues  a  PMD  to 
the  assigned  lead  and  support  centers  which  clearty  identifies  specific  responsibilities  of  those  agencies 
whose  efforts  are  required  for  completing  the  Phase  0  activities  (D21  and  D78).  PMDs  will  include  the 
following  information: 

(1)  Assignment  of  Implementing.  Partic^ating.  Operating  Commands  and  Test  Agency, 

as  required. 


(2)  Identification  of  requirements  documents  (i.e.  Mission  Need  Statement  (MNS))  and 
related  documents  (i.e.,  Threat,  Defense  Planning  Guidance  (DPG),  etc.). 

(3)  Identify  Operating  Command  responsible  for  establishing  the  Concept  Action  Group 
(CAG)  and  leading  the  concept  studies. 

(4)  Identify  funding  amount  and  source  and  minimum  set  of  study  alternatives. 

(5)  Direct  development  of  the  Cost  and  Operational  Effectiveness  Analysis  (COEA)  and 
Operational  Requirements  Document  (ORD). 

(6)  Identify  responsible  Phase  0  participarrts. 

(7)  Identify  required  documentation  and  schedule  considerations  for  the  next  milestone. 

(8)  Establish  review  and  coordination  procedures  for  next  milestone  decision. 
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b.  If  the  decision  from  the  MDA  affects  any  programs  already  urxjer  deveiopmeni,  then  the 
PEOs  or  Program  Element  Monitors  (PEMs)  who  are  responsible  for  those  programs  need  to  be  involved 
to  ensure  that  their  PMOs  are  chang^  to  support  ADM  tasks. 

c.  The  PMD  is  not  a  budgetary  document  and  provides  no  obligation  (funding)  authority. 

d.  The  PMD  is  coordin^ed  with  all  major  command  level  organizatiorts  tasked  with  direction 
prior  to  being  coordinated  throughout  the  head^arters.  It  is  the  responsibiily  of  the  originating  office  to 
ensure  fun  and  complete  distribution  of  the  final  document  in  accordance  with  the  mandate^  distribution 
list  in  SAP  Headquarters  Operating  Instmction  (HOI)  800*2,  Attachment  6.  In  addition  to  this  list,  the 
originating  office  creates  a  project  specific  (tistrixjtion  list  for  organizations  listed  in  the  PMD.  At  the 
very  least,  this  list  will  be  comprised  of  the  Implementing  Command.  MDA,  Project  Director,  and  any 
headquarters  and  field  offices  tasked  in  the  PMD. 

e.  SAP  HOI  800*2  (DRAR)  details  all  policy,  procedures  and  documentation  requiremertts  for 
completing  and  coordinating  PMDs  and  irx^udes  sanple  formats  for  the  various  types  of  PMDs.  A  copy 
of  this  Draft  HOI  may  be  found  in  the  YX  Library. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  This  activity  starts  with  the  issuance  of  an  ADM  by  the  MDA  (A9  and  B9). 

b.  Exit:  Issuance  of  the  PMD  to  the  appropriate  agencies  (D21  and  D78). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  ADM  (A9  and  B9) 

b.  Outputs:  PMD  (021  and  078) 

10.  KEY  REFERENCES: 

a.  SAP  HOI  800-2,  Policy  and  Guidance  for  Preparing  Program  Management  Directives,  1  Jan 
93  (DRAR),  details  all  policy,  procedu  it'S,  and  documentation  requirements  for  completing  and 
coordinating  PMDs  and  includes  sample  formats  for  the  various  types  of  PMDs. 

b.  Air  Force  Acquisition  Model  (APAM) 

11.  IMPLEMENTATION  TOOLS:  None  identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  PMD  will  be  issued  upon  receipt  of  the  ADM.  Subsequent  PMDs  will  be 
issued  within  45  days  of  the  annual  submission  of  the  President's  Budget  (PB),  or  at  the  issuance  of  a 
subsequent  ADM  based  on  an  MDA  decision. 

b.  CONSTRAINTS:  None  identified. 

c.  RESOURCES:  Project  office  support  in  preparing  the  PMD  should  be  expected. 

d.  LESSONS  LEARNED:  There  are  no  lessons  learned  regarding  Milestone  0  PMDs  due  to  the 
small  number  of  MNSs  that  have  been  approved  based  on  the  new  DoD  5(X)0  series  requirements,  per 
AF/XORJ. 
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•.  BEST  PfUUniCES:  Close  coordination  b^een  the  project  office  and  the  AF/XOR  during 
the  writing  of  the  PMO  can  help  to  prevent  problems  later.  If  possible,  the  project  office  should  offer  to 
write  a  draft  PMO  to  aid  AF/XOR.  It  is  impr^ant  that  the  new  PMD  be  analyzed  immediately  upon 
receipt  in  order  to  identify  areas  of  responstoility.  appropriate  OPRs  and  to  determine  executabHity  of  the 
PMD. 


f.  TRAPS:  A  poorly  written  or  inappropriate  PMD  can  direct  designs/solutions  or  program 
schedules  prematurely.  In  these  cases  the  project  office  must  get  back  to  the  originating  agency  to 
reUeve/loo^  the  direction  preferably  during  the  coordination  process. 
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1.  ELEMENT:  B11,  TBS  1.1. 4.5.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Provide  AF/IN  Threat  Support 

3.  ELEMENT  OWNER(S):  HQUSAF/IN 

4.  ELEMENT  STMaEHOLDEfl(S):  HQ  ARSA/INAA.  HQ  USAF/INX.  HQ  ARC.  Product  Center  Director 
of  Intelligence  (Dl),  HQ  USAF/ICO,  OIA,  HQ  USAF/XOR,  Operating  Command,  and  Implementing 
Command. 


5.  REQUIREMENT: 

a.  OoO  Directive  5000.1,  Defense  Acquisition.  23  Feb  91,  Part  1.  This  regulation  contains 
information  on  the  relationship  of  threat  assessment  to  the  acquisition  process. 

b.  DoD  Instniction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 .  Part  4.  This  regulation  addresses  policies  and  procedures  for  production,  review,  and  validation  of 
intelligence  information  in  support  of  defense  acquisition  programs. 

c.  AF  Regulation  200-13,  Intelligence  Support  to  the  Requirements  and  Acquisition  Processes. 
20  Jul  92.  This  regulation  states  the  Air  Force  policy  for  identifysig  and  acquiring  intelligence  to  support 
the  Air  Force  requirements  and  acquisition  processes. 

6.  PURPOSE/OBJECnVEfS): 

a.  Purpose;  Manage  threat  and  intelligence  infrastructure  support  throughout  the  acquisition 
process  from  need  determination  to  operational  employment. 

b.  Objectives:  Ensure  that  the  effectiveness  of  a  proposed  system  within  its  intended  threat 
environment  be  a  fundamental  concern  of  the  acquisition  effort. 

7.  DESCRIPTION: 

a.  Threat  assessments  are  produced  to  support  the  requirements  and  acquisition  processes. 
They  are  a  key  factor  in  determining  mission  needs.  HQ  USAF/IN  in  concert  with  the  Defense 
Intelligence  Agency  (DIA)  provides  Intelligence  and  Threat  support  to  the  Concept  Action  Group  (CAG) 
which  is  lead  in  the  development  of  the  Cost  and  Operational  Effectiveness  Analysis  (COEA)  and  the 
Operational  Requirements  Document  (ORD)  (both  documents  address  threat).  The  CAG  is  the  Phase  0 
study  group  formed  to  explore  materiel  alternatives  and  ensure  that  implementing  organizations  notify 
HQ  USAF/IN  and  DIA  to  devefop/update  threat  asessmertt  documents.  However,  the  CAG  membership 
should  include  representatives  from  AF/IN  and  DIA  to  address  intelligence  (threat)  issues  needed  to 
achieve  Phase  0  objectives  (Cl  6).  The  foltowing  paragraphs  further  explain  how  AF/IN  provides  threat 
support  to  the  acquisition  process  between  Milestone  0  and  Milestone  I: 

b.  HQ  AFISA/INA  manages  threat  support  to  Air  Force  acquisitions  for  HQ  USAF/IN.  The 
Product  Center  Dl  (ASC/NAIC/TIA  for  ASC)  is  the  focal  point  for  obtaining  threat  support  for  an 
acquisition  program.  The  System  Threat  Cessment  Report  (STAR)  is  the  authoritative  reference  for 
threat  data  supporting  a  major  acquisftion  program  (D50).  STARs  are  required  for  Acquisition  Category 
(ACAT)  1C  and  1 D  programs,  and  for  major  modifications  as  defined  by  DoD  5000.2  and  Air  Force 
Policy  Directive  10-6.  The  System  Threat  Assessment  (STA)  is  the  authoritative  threat  reference  for 
threat  data  supporting  ACAT  ll-IV  programs  and  is  formatted  like  a  STAR.  STAs  for  ACAT  II  programs 
are  stand-alone  documents  of  about  25  pages.  STAs  for  ACAT  lll-IV  programs  are  contained  in  the 
ORDs,  and  are  normally  two  to  five  pages.  When  no  ORD  exists  for  ACAT  lll-IV  prograrrrs,  the 
appropriate  Threat  Environment  Description  (TED)  suffices  (B2). 
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c.  The  DIA.  as  piincipa)  advisor  to  DoD  Components  tor  inteiligence  and  threat  concerns,  is 
rMponsi)le  lor  reviewing  and  validating  some  of  the  DoO  component  produced  threat  documents 
relating  to  acquisition  projects  (A10). 

d.  HQ  AFISA/INA  provides  the  substantive  threat  review  of  all  ORD  threat  assessments  for  the 
Air  Staff.  The  ORO  threat  assessment  should  be  similar  to  the  STAR  format,  as  applicable.  HO 
USAF/INX  reviews  all  ORDs  to  ensure  adequate  inteiligence  mfrastnjcture  exists  to  support  a  weapon 
system  requirement.  Infrastructure  components  include  data  flow  and  data  bases;  target  materials; 
nrapping,  charting  and  geodesy;  system  interfaces;  security  classification;  and  personnel  and  training. 

e.  Prior  to  Milestone  I,  for  HQ  USAF/XO  and  SAF/AQ  selected  projects,  the  Operatsig 
Command  and  HQ  USAF  Intelligence  Counterpart  Officers  (ICOs)  form  an  lnlelligerx;e  Support  Working 
Group  (ISWQ)  to  detennine  weapon  system-specific  intelligence  requirements  and  costs.  Working  with 
HQ  USAF  inteiligence  functional  managers,  ICOs  draft  required  inteligence  inputs  for  a  proposed 
acquisition  program.  These  initial  inputs  and  associated  costs  are  inoorporated  into  the  initial  COEA  as 
part  of  the  projected  life  cycle  cost  for  a  given  project. 

f.  During  the  Program  Management  Directive  (PMD)  preparation  and  update  process,  SAF/AQ 
coordinates  the  PMD  with  HQ  AFISA  and  HQ  USAF/INX  to  make  sure  threat  arid  infrastnjcture  support 
are  properly  tasked  to  support  the  proposed  program. 

g.  HQ  AFISA  and  HQ  USAF/INX  approve  threat  or  intelligence  infrastnjcture  matters  in  the 
Integrated  Program  Summary  (IPS),  the  Test  and  Evaluation  Master  Plan  (TEMP),  Operational  Test  Plan 
(OTP),  and  COEA. 

h.  Unique  and  tailored  threat  documentation  to  support  the  AF  systems  survivability  program  will 
be  produced  by  the  intelligence  community  and  be  HQ  USAF/IN  approved. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Whenever  requested,  whether  by  the  user  or  the  acquisition  community,  HQ 
USAF/IN  will  provide  supfxjrt  using  key  data  extracted  from  approved  intelligence  community  threat 
information. 

b.  Exit;  Corkinuous  threat  and  intelligence  support  to  the  project  office  throughout  the 
acquisition  process  from  determination  of  need  to  operational  employment. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  Current  validated  DIA  threat  information,  the  threat  environment  documented  in  the 
Mission  Need  Statement  (MNS)  and  the  Program  Management  Directive  (PMD)  (Cl 2  and  BIO). 

b.  Outputs;  Continuous  intelligence  support  to  the  project  office  by  providing  input  and  review  of 
threat  documentation  to  ensure  the  effectiveness  of  a  proposed  system  within  its  intend^  threat 
environment. 
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10.  KEY  REFERENCES: 


a.  AF  Instruction  10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,  16  Feb  93.  Paragraphs  1 .1 .4, 1 .1 .7,  and  1 .2.3.  This  regulation  discusses  *task-to-need,‘ 
threat  assessments  in  determining  mission  needs,  and  Phase  0  stucfies. 

b.  AFSC  Regulation  200-3,  Theat  Assessment  Documentation,  5  Apr  85,  Atch  1 .  This 
regulation  addresses  HQ  AF/IN  responsibilities  and  the  threat  and  intelligence  database. 

c.  DIAR  55-3,  Intelligence  Support  for  Defense  Acquisition  Programs,  30  Mar  92.  This 
regulation  addresses  overall  intelligence  support. 

11.  IMPLEMENTATION  TOOLS: 

a.  The  formulation  of  a  Threat  Steering  Group  (TSG)  is  an  effective  means  of  providing  active 
threat  support  to  Joint  Service  or  complex  system  acquisitions.  The  TSG  acts  as  an  advisory  body  on 
threat  matters.  K  is  a  Joint-Service  ar^  ad  hoc  intelligence  group.  When  the  Air  Force  is  le^  Service, 
this  group  would  normally  be  chaired  by  HQ  AFISA. 

b.  The  Threat  Working  Group  (TWG),  chaired  by  the  project  team,  gives  advice,  guidance,  and 
recommendations  to  the  program  manager  on  effective  responses  to  the  threat  environment.  The  TWG 
should  include  representatives  from  the  project  team  and  the  appropriate  Director  of  Intelligence  (Dl).  It 
should  also  include  representatives  from  the  using  commands  and  contractor  personnel.  See  D50  for 
additional  information  on  TWG. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  DoD  policy  requires  that  the  effectiveness  of  a  proposed  system  within  its 
intended  environment  be  a  fundamental  concern  of  the  acquisition  effort.  Therefore,  AF/IN  threat 
support  is  an  ongoing  effort  through  all  phases  of  the  systems  acquisition  process. 

b.  CONSTRAINTS:  Resources  as  defined  in  next  paragraph. 

c.  RESOURCES: 

(1)  HQ  AFISA  uses  two  to  three  project  teams  for  threat  support.  For  example,  they  are 
presently  divided  into  two  teams;  1  for  Space  and  Electronic  Combat  Systems  and  1  for  Weapons  and 
Aircraft.  Out  of  those  teams,  one  Threat  Support  Program  Manager  handles  three  to  four  specific 
programs  with  back  up  personnel  as  needed. 

(2)  The  project  team  needs  to  designate  a  point  of  contact  (POC)  within  the  project 
office  to  interface  with  the  Product  Center  Dl  for  intelligence  support.  This  will  enable  project  teams  to 
be  kept  up-to-date  on  changes  in  the  threat  environment  and  obtain  guidance  and  recommendations  on 
any  new  irrtelligence  issues  that  may  apply  to  their  projects. 

d.  LESSONS  LEARNED:  Early  and  continued  collaboration  amorrg  the  intelligence  community 
and  the  Operating  and  Implementing  Commands  will  expedite  the  development,  review,  approval,  and 
validation  of  threat  documentation  and  help  to  ensure  the  availability  of  valid  threat  assessmertis  in  a 
timely  manner.  The  TWG  seems  to  be  the  best  approach. 
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0.  BEST  PRACTICES: 

(1 )  Use  only  threat  data  sources,  to  include  the  target  data  base,  and  assessment 
procedures  which  have  been  validated  by  DIA  in  preparing  system  assessments  for  ACAT I  through  IV 
programs  and  higfily  serrsitive  classified  programs. 

(2)  Participate  with  the  DIA  and  AF/IN  in  the  development  and  implementation  of  long 
range  forecasting  methodologies  and  threat  integration  technk^es. 

(3)  Have  a  constant,  ongoing,  dynamic  between  cost,  schedule,  technology,  threat,  and 
security  risk.  These  are  interactive  and  should  be  managed  in  concert  rather  than  as  separate  risk 
issues. 


(4)  To  ensure  common  threat  data  across  a  given  project  or  program,  get  it  right  in  the 
STAR  or  STA  and  reference  -  -  don1  repeat  •  -  the  STAR  or  STA  in  other  documents,  e.g.,  ORD,  TEMP, 
COEA,  etc. 

(5)  To  ensure  full  system  capability,  identify  rec^ired  intelligerKre  infrastructure 
components  early. 

(6)  Meet  schedule  requirements  to  ensure  adequate  time  for  review  and  validation. 

f.  TRAPS:  Failure  to  maintain  consistency  when  producing  the  various  threat  documents  for  a 
given  project  may  lead  to  misunderstanding,  confusion,  rewrites  and  failure  to  gain  approval  and 
validation.  See  best  practices  (3)  above. 
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1.  ELEMENT:  B13,  TBS  1. 2.3.8  2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Update  Program  POM/BES  Input 

3.  ELEMENT  OWNER:  Secretary  of  the  Air  Force  (SECAF) 

4.  ELEMENT  STAKEHOLDER(S):  Air  Force  Chief  of  Staff  (CSAF).  HQ  USAF  Directorate  of  Progratm 
and  Evaluation  (AF/PE),  Air  Force  Comptroller  (SAF/FM),  D^ty  Chief  of  Staff  for  Plans  arxi 
Operations  (AF/XO),  Program  Element  Monitor  (PEM),  MAJCOMs,  arxj  Project  Manager. 

5.  REQUIREMENT:  OoD  Directive  7045.14,  The  Planning,  Programming,  and  Budget  System  (PPBS). 
22  May  84. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  purpose  of  this  activity  is  to  update  (cr  create)  approved  Air  Force  financial 
planning  documentation.  For  a  specific  project  office,  the  Program  Objective  Memorandum  (POM),  and 
(to  a  lesser  extent)  the  Budget  Estimate  Submission  (BES),  are  the  primary  opportunities  for  a  project 
office  to  submit  project/program  requirements  into  approved  Air  Force  planning  documentation. 

b.  Objective;  The  objective  is  for  the  Air  Force  to  develop  a  comprehensive  and  integrated  plan 
which  supports  the  Defense  Planning  Guidance  (A1 ).  At  the  project  level,  it  should  be  the  objective  of 
the  of  the  project  office  to  get  the  program  financial  requirements  approved  at  the  earliest  opportunity  to 
prevent  schedule  delays  due  to  funding  availability. 

7.  DESCRIPTION: 

t  a.  National  security  policy,  as  documented  in  the  Defense  Planning  Guidance  (DPQ);  provides 

guidance  to  the  Services  for  POM  development  around  December  in  the  odd-numbered  years  .  This 
provides  the  SECDEF's  fiscally-constrained  guidance  on  policy,  strategy,  force  planning,  and  resource 
planning.  During  this  same  time  frame,  OSD  provides  the  POM  documentation  requirements,  the  POM 
Preparation  Instructions  (PPI)  to  the  Services.  Based  on  this  information,  all  MAJCOMs,  Field  Operating 
Agencies,  and  Direct  Reporting  Units  provide  POM  inputs  to  the  Air  Staff.  The  subsequent  Air  Staff 
activities  are  the  subject  of  this  element. 

b.  The  development  of  the  POM  is  the  process  by  which  ait  Air  Force  resources  required  to 
execute  OSD  Defense  Planning  Guidance  (Blo^  At )  are  documented  and  validated.  [For  a  specific 
project,  the  POM  represents  an  opportunity  to  get  the  projected  resource  requirements  documented  in 
the  Program  Cost  Estimate  (e.g.,  D47)  approved.]  The  POM  is  used  to  update  the  planning  tor  the  6 
years  contained  in  the  Future  Year  Defense  Program  (FYDP).  The  FYDP  is  the  official  DoD  database 
and  document  which  is  a  compilation  of  the  total  resources  (forces,  manpower,  and  dollars)  programmed 
for  DoD.  arranged  by  Major  Force  Program  (MFP)  and  appropriation.  The  R'DP  projects  6  years  for  all 
data  except  forces,  which  extend  an  additional  3  years.  After  OSD  adjustments  are  made  to  the  POM, 
the  Air  Force  is  allowed  to  update  and  reprice  the  programs  which  were  approved  .  This  is  documented 
in  the  Budget  Estimate  Submission  (BES),  which  emphasizes  the  first  2  years  of  the  FYDP,  and  converts 
the  program  oriented  format  of  the  POM  into  the  appropriation  categories.  The  BES  is  a  primary  input  to 
the  President's  budget  submission  to  Congress,  and  if  supported,  eventually  program  budget 
appropriations. 

c.  The  current  stmcture  for  the  Air  Force  corporate  review/screening  process  was  established  in 
1991 ,  with  the  creation  of  eight  Resource  Allocation  Teams  (RATs).  The  RATs  are  the  focal  points  for 
resource  issues  for  the  following  functional  areas;  Nuclear  Deterrence.  Power  Projection,  Gk^l 
Mobility,  Space  and  CCCI,  Materiel  Support,  Personnel  Support,  Classified  Programs,  and  National 
Foreign  Intelligence  Programs.  HQ  USAF  Directorate  of  Programs  and  Evaluation  (AF/PE)  is  the  office 
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of  primary  responsibility  for  the  Resource  Allocation  Process.  Another  key  player  in  the  POM  process  is 
the  Program  Element  Monitor  (PEM),  who  is  the  overall  focal  point  for  the  programs  wKhin  his  Program 
Element.  The  PEM  is  responsible  for  addressing  ail  issues  corrceming  his  programs.  In  short,  since 
every  Program  Element  (PE)  is  assigned  to  a  RAT,  the  PEM  must  interface  with  that  team  to  ensure  his 
PE  is  properly  supported. 

d.  The  Program  Objective  Memorandum;  In  the  fait  of  the  odd-numbered  years,  the  MAJCOMs 
provide  their  POM  proposals  to  HQ  USAF.  These  include  a  priontized  list  of  disconnects  and  any  ’new 
starts’  that  are  proposed.  The  RATs  convene,  and  with  the  support  of  the  functional  staffs,  SAF/FM  and 
AF/PE,  the  teams  review  and  evaluate  the  MAJCOM  inputs.  Based  on  the  POM  inputs,  the  RATs 
generate  program  options  for  presentation  to  the  Air  Force  Council,  CSAF,  and  SECAF  from  late 
January  until  early  March  (of  the  even-numbered  years).  During  this  same  period,  the  players  update  the 
POMs  to  reflect  any  Congressional  budget  activities,  the  President's  Budget  submission  to  Congress, 
OSD  budget  exercises  or  fiscal  guidance,  and  new  OSD  Defense  Planning  Guidance  or  Air  Force 
Planning  Guidance. 

e.  At  the  completion  of  the  POM  deliberations,  SAF/FM  verifies  the  pricing  of  the  approved 
options,  and  the  final  Air  Force  POM  is  documented  and  coordinated.  The  POM  is  submitted  to  OSD  on 
1  April  (A12)  arrd  at  this  time,  SAF/FM  updates  the  FYDP  to  reflect  the  Air  Force  approved  position.  At 
the  OSD  level,  any  SECDEF  decisions  to  adjust  the  service  POMs  are  recorded  in  Program  Decision 
Memorandums  (PDMs). 

f.  The  Budget  Estimate  Submission;  The  first  step  in  the  BES  process  is  the  Air  Force  Summer 
Review.  SAF/FM  performs  the  Summer  Review,  which  consists  of  an  evaluation  of  the  pricing  and 
execution  of  the  Air  Force  investment  accounts.  Program  and  financial  information  from  this  review, 
plus  any  PDMs  issued  by  OSD,  and  any  necessary  repricing  of  elements  in  the  oatabases,  is  used  to 
develop  the  Air  Force  Budget  Estimate  Submission,  which  occurs  in  August/September.  Note;  While 
the  project  offices  can  expect  to  be  tasked  to  develop  program  documentation  to  support  budget 
requirements  in  the  BES  exercise,  normally  only  limited  (if  any)  adjustments  to  the  approved  Air  Force 
position  are  allowed. 

g.  At  this  time,  the  project  may  not  need  funding  for  many  years,  but  if  funding  will  be  required 
in  any  of  the  years  addressed  in  the  POM,  it  is  essentia!  to  submit  the  financial  requirements  for  the 
program.  The  project  office  must  establish  these  financial  requirements  in  Air  Force  planning  data  bases 
as  soon  as  possible  to  ensure  that  all  funding  is  available  to  support  execution  of  the  planned  program. 

8.  ENTRANC&EXIT  CRITERIA: 

a.  Entrance;  The  POM  activities  in  the  field  start  in  the  spring  of  the  odd-numbered  years,  when 
the  Secr^ariat/Air  Staff  provides  each  MAJCOM  with  the  dollar  and  resource  baselines  each  should  use 
to  derive  the  MAJCOM  POM  packages.  In  the  summer,  AF/PE  publishes  the  POM  Preparation 
Instmctions,  which  outlines  detailed  instructions  and  submission  schedules.  In  the  fall,  the  MAJCOM 
POM  inputs  (C22)  are  submitted  to  HQ  USAF.  The  MAJCOMs  are  tasked  to  generate  the  BES  in  mid 
summer  of  the  even-numbered  years,  and  Air  Force  activity  starts  upon  receipt  of  the  MAJCOM  inputs 
(C22)  in  August-September. 

b.  Exit;  For  the  POM,  the  activity  is  completed  with  the  delivery  of  the  Air  Force 

POM  (in  both  hard  copy  and  computer  file)  to  OSD  (At  2)  at  the  first  of  April  in  the  even-numbered  years. 
For  the  BES,  the  activity  is  completed  with  the  submission  of  the  BES  to  OSD  in  mid-September  of  the 
even-numbered  years  (A12). 


9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs;  For  the  POM,  information  necessary  to  start  the  activity  is  contained  in  the  Defense 
Planning  Gui^rx»  (At ),  Air  Force  Planning  Guidance,  the  FYOP  and  the  MAJCOM  specific  baselines, 
and  the  POM  Planning  Instructions.  The  USAF  POM  review  process  requires  the  POM  submissions 
(C22)  from  the  MAJCOMs.  For  the  BES,  results  of  the  Summer  Review,  and  the  receipt  of  Program 
Decision  Memorandums  from  OSD  and  the  MAJCOM  BES  submissions  (C22)  are  necessary. 

b.  Outputs;  For  both  the  POM  arxf  the  BES,  the  output  is  the  delivery  of  the  Air  Force  approved 
documentation  to  OSD  (At  2). 

10.  KEY  REFERENCES:  The  references  below  provide  more  specific  implementation  guidance. 

a.  AFP  172-4,  The  Air  Force  Budget  Process,  Oct  87  -  Describes  the  Air  Force  budget  process. 

b.  DoDI  7045.7,  Implementation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 
23  May  84  -  Describes  the  budget  process  within  the  Department  of  Defense. 

11.  IMPLEMENTATION  TOOLS:  The  PPBS  Primer.*  7th  Edition,  May  93.  This  document  is  published 
by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and  provides  a  valuable 
d^ription  of  the  current  PPBS  process.  This  is  one  of  the  few  documents  that  describes  the  current 
process,  and  K  does  so  in  detail.  Further,  it  defines  the  activity  schedule  for  the  development  of  the 
FY96  POM. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  After  receipt  of  the  MAJCOM  POM  inputs  in  the  fall.  Air  Force  works  POM 
iterations  through  the  following  March.  The  BES  activities  occur  from  August  through  mid-September, 
when  the  approved  documentation  is  delivered  to  OSD. 

b.  CONSTRAINTS:  The  primary  constraints  to  this  activity  are  the  resource  limitations  placed 
on  the  Air  Force  by  OSD.  and  the  schedule  limitations  on  management  reviews  inherent  in  the  budget 
timetable. 

c.  RESOURCES:  The  POM  deliberations  in  the  Air  Staff  require  intensive  activity  by  the 
Resource  Allocation  Teams,  AF/PE,  SAF/FM,  and  the  functional  staffs  to  reconcile  planning  objectives 
and  resources.  The  BES  generation  is  also  a  major  exercise,  but  is  more  limited,  since  it  represents  a 
financial  repackaging  of  the  approved  Air  Force  program. 

d.  LESSONS  LEARNED:  During  the  Air  Staff  POM  deliberations  and  reviews,  it  is  important 
that  the  project  manager  keeps  in  close  contact  with  the  project  representative(5)  in  AF/XO  (and 
SAF/AQ,  if  someone  has  been  identified).  This  is  important  to  help  resolve  issues  that  may  arise,  and  to 
ensure  that  they  fully  understand  all  the  pertinent  aspects  of  the  project,  and  can  defend  the  projected 
resource  requirements.  Also,  development  of  the  POM  is  a  comprehensive  and  complex  ta^,  and  the 
information  requested  can  be  expected  to  change  with  every  submission.  Therefore,  the  POM  preparer 
in  the  project  office  needs  to  ensure  that  (s)he  is  not  only  in  compliance  with  the  formal  tasking  and  the 
local  budget  staff  instructions,  but  also  satisfies  the  information  and  documentation  needs  of  the  Air  Staff 
project  representative. 

e.  BEST  PRACTICES:  After  submission  of  the  POM  package,  the  project  office  should  posture 
itself  to  be  able  to  respond  effectively  to  programmatic  questions,  and  to  be  able  to  generate  quantitative 
answers  to  Air  Staff  requests  to  develop  and  price  out  program  variations  to  the  POM  submission.  The 
capability  to  generate  quality  "what-if  information,  often  within  hours,  is  important,  since  the 
reconciliations  and  rankings  to  be  performed  by  the  Resource  Allocation  Teams  may  require 
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modifications  to  the  MAXOM  POM  request  programs  in  terms  of  funding  levels,  quantities,  schedules, 
or  other  programmatic  aspects.  If  a  project  office  is  unable  to  provide  necessary  information  in  time  to 
support  the  decision  makers,  the  project  may  not  be  supported,  or  may  be  approved  with  insufficient 
funding  levels. 

f.  TRAPS:  If  the  POM  is  the  first  for  the  project,  the  submission  will  be  considered  a  *New 
Start,"  and  identified  as  such.  There  may  be  additional  documentation  requirements  and  a  higher  level 
of  review  for  these  programs,  since  there  is  not  an  existing  funding  line.  Due  to  this,  the  project  office 
must  be  especiaHy  prepared  to  defend  project  requirements. 
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1.  ELEMENT:  B14,  TBS  1. 2.2.3  IFC  93-3 

2.  ELEMENT  TITLE:  Prepare  for  Requirements  Summit 

3.  ELEMENT  OWNER(S):  AF/XOR 

4.  ELEMENT  STAKEHOLDER(S):  Chief  of  StaH  of  the  Air  Force  (CSAF),  SAF/AQ,  Operating 
Commands,  Program  Executive  Officers  (PEO),  Air  Force  Operational  Test  Agency,  Air  Force  Material 
Command  (AFMC),  and  Air  Educational  Training  Command  (AETC). 

5.  REQUtREI/ENT:  SAF/AQ  Policy  90M-006,  Requirements  and  Acquisition  Program  Review. 

6.  PURPOSE/OBJECTIVES:  The  purpose  of  this  element  is  to  do  all  of  the  work  necessary  to  prepare 
the  briefing  for  the  Requirements  and  /^uisition  Program  Review  (Summit).  The  objectives  of  this 
element  are  to  identify  the  programs  that  warrant  a  Summit,  task  the  participants  to  support  the  Summit 
process,  establish  and  coordinate  Summit  objectives,  prepare  the  Summit  briefing,  and  present  the 
briefing  to  the  pre-Summit  reviews. 

7.  DESCRIPTION: 

a.  The  Summit  preparation  and  review  activities  can  be  thought  of  in  three  phases  --  tasking, 
preparation,  and  review.  The  tasking  phase  includes  identifying  those  programs  that  hold  Summits  and 
the  organizations  and  personnel  who  need  to  participate.  All  Acquisition  Category  (ACAT)  I  programs 
are  retired  to  hold  a  Requirements  and  Acquisition  Program  Review  (Summit)  tefore  Milestone  I  or  at 
other  times  requested  by  CSAF.  ACAT  II,  III,  aixf  IV  programs  can  be  nominated  for  a  Summit  by 
SAF/AQ,  AF/XO,  AFMC  or  the  Using  Command  for  any  issue  that  would  require  a  senior  level  review. 
Any  recommendation  for  a  Summit  must  be  approved  by  CSAF.  Summit  membership  consists  of  the  Air 
Force  Acquisition  Executive  (AFAE),  the  Commanders  of  the  Operating  Command(s)  having  specific 
interest  in  the  program  being  reviewed.  Commanders  of  AFMC  and  AFOTEC,  AF/XO,  AF/IN,  AF/LG,  the 
appropriate  SAF/AQ  PEO  and  mission  area  director,  and  the  AFMC  program  director  for  the  program 
being  reviewed.  AF/XOR  holds  a  kickoff  meeting  for  Summit  participants  where  the  Summit  process  is 
explained,  plans  and  schedules  are  developed,  duties  and  working  group  members  are  assigned, 

Summit  objectives  and  goals  for  the  p^ram  are  identified,  lessons  learned  from  previous  Summit 
processes  are  briefed,  and  the  Summit  briefing  format  is  provided. 

b.  The  briefing  preparation  phase  is  where  all  the  work  gets  done.  The  working  gioupis  review 
national  guidance  and  strategies  (At  and  B1 )  and  track  through  the  Mission  Area  Assessment  (MAA  - 
C1),  Mission  Need  Analysis  (MNA  -  C3),  scenarios.  Concept  of  Operations  (CONORS  -  C2),  and  Mission 
Ne^  Statement  (MNS  -  A6)  for  the  system.  They  then  document  how  system  requirements  have  been 
added,  deleted  or  nxxjified  during  the  development  of  the  Operational  Requirements  Document  (ORD  - 
C26),  validate  the  thresholds  and  goals  through  the  use  of  tradeoff  analyses,  and  identify  the  cost, 
schedule  and  technical  drivers  to  understand  how  the  critical  requirements  were  selected.  The  Cost  and 
Operational  Effectiveness  Analysis  (COEA  -  C23)  is  reviewed  to  understand  the  rationale  for  the 
preferred  altemative(s)  selection  (C25)  and  how  the  altemative(s)  stack  up  against  the  requirements. 
Once  this  ’requirements  audit  traiP  is  understood,  the  Summit  briefing  is  prepared  to  identify  any  key 
issues. 


c.  The  briefing  is  first  given  to  the  Colonel-level  and  then  to  a  1  to  2-star  level.  Issue  resolution 
options  are  addressed  at  the  1  to  2-star  review  and  incorporated  into  the  briefing.  The  briefing  then  gets 
reviewed  at  the  3-star  level  at  which  major  issues  or  questions  are  elevated  and  solutions  are 
recommended.  The  briefing  is  now  rea^  for  the  4-star  Summit  (B1 5). 
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8.  ENTRANCE/EXIT  CRITERIA: 

a.  Enirwice:  For  ACAT  I  programs,  the  process  starts  with  receipt  of  the  Major  Defense 
Acquisition  Programs  (MDAP)  list.  The  Summit  process  would  begin  so  that  the  Summit  briefing  occurs 
at  least  180  days  before  the  Defense  Acquisition  Board  (DAB)  or  Joint  Requirements  Oversight  Council 
(JROC)  meetings.  For  other  programs,  the  process  starts  with  the  recomrnendation  of  a  Summit  to 
CSAF. 


b.  Exit:  A  briefing  ready  for  the  4-star  Summit,  complete  with  issue  resolution 
recommendations. 

9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs: 

Inmit  nnmirtwfit 

Source 

Status 

Mission  Need  Statement  (MNS  -  A6) 

User 

Validsaed 

Operational  Requirements  Document  (ORD  -  C26) 

User 

Approved 

Cost  ano  Operational  Effectiveness  Analysis  (COEA  -  C23) 

User 

Approved 

Concept  of  Operations  (CONORS  -  C19) 

User 

Final 

Test  and  Evaluation  Master  Plan  (TEMP  -  054) 

SPO 

Draft 

Acquisition  Program  Baseline  (APB  -  051 ) 

SPO 

Draft 

System  Threat  Assessment  (Report)  (STA(R)  -  D50) 

SPO 

Draft 

(1)  These  documents  must  be  available  for  review  by  the  Summit  working  groups.  The 
ORD  must  be  current,  complete,  and  approved  by  the  MAJCOM/CC.  These  documents  will  be 
thoroughly  reviewed,  understood  and  scrubbed  biy  the  working  group  to  form  the  basis  of  the  Summit 
briefing. 

b.  CXitputs.  Scrubbed  ORD  and  ROM 
Requirements  audit  trail. 

Rigorous  tradeoff  analysis  identifying  critical  operational  requirements. 

Revised  program  schedule. 

Summit  briefing. 

10.  KEY  REFERENCES: 

a.  AF1 1 0-601 ,  paragraph  1.11. 

b.  SAF/AQ  Acquisition  Policy  90M-006.  Requirements  and  Acquisition  Program  Review. 

c.  SAF/AQ  Requirements  and  Acquisition  Program  Review  (Summit)  Process  Guide. 

11.  IMPLEMENTATION  TOOLS:  SAF.rAQ  Requirements  and  Acquisition  Program  Review  (Summit) 
Process  Guide,  Revision  4, 4  May  9?.  SAF/AQX  is  the  OPR  for  Summit  policy  and  publishes  the 
approved  list  of  MDAPs.  This  offic-?  ai^o  publishes  the  Kst  of  all  Air  Force  acquisition  programs  by 
ACAT.  The  MDAP  list  should  serve  the  initial  planning  document  for  calling  the  mandatory  Summit 
reviews.  SAF/AQX  is  responsible  for  maintaining  the  process  guide  and  the  library  of  Summit  minutes 
and  lessons  learned. 

12.  PLANNING  GUIDANCE:  The  SAF/AQ  Requirements  and  Acquisition  Program  Review  (Summit) 
Process  Guide  is  a  good  source  for  information  presented  in  this  paragraph. 
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a.  DURATION:  Should  aHow  for  90  days  to  prepare  tor  the  actual  Summit  if  aN  prior  inputs 
have  been  completed  and  documented. 

b.  CONSTRAINTS:  N/A 

c.  RESOURCES:  Representatives  from  all  of  the  stakeholder  organizartions  will  probably  be 
committing  1 00%  of  their  time  to  this  activity  during  this  90  day  period  .  There  may  be  some  computer 
simulations  and/or  analyses  needed  done  by  the  product  centers,  conference  rooms  utiMzed, 
administrative  assistance  provided  and  travel  arrangements  made. 

d.  LESSONS  LEARNED:  While  some  Milestone  II  Summits  have  been  converted,  there  have 
been  no  Milestone  I  Summits  to  date.  To  avoid  wasted  time  and  effort  when  the  CSAF  approves  a 
Summit,  AF/XO  should  immertiately  clarify  the  Summit  purpose  and  each  participant's  responsibilities. 

e.  BEST  PRACTICES:  When  a  Summtt  is  announced,  the  Action  Officer  should  request 
information  through  SAF/AQX  on  lessons  learned  and  process  improvements. 

f.  TRAPS:  Despite  AF1 10-601  guidance,  some  Summits  have  been  scheduled  without 
notification  to  CSAF.  To  avoid  confusion  and  unneccessary  workload,  anyone  proposirtg  a  Summit  for  a 
non-MDAP  program  should  fully  coordinate  their  request  prior  to  the  issuance  of  the  Summit  taskirtg. 
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1.  ELEMENT:  BIS,  TBS  1. 2.2.4  (IFC  93  3) 

2.  ELEMENT  TITLE:  Conduct  Requirements  Summit 

3.  ELEMENT  OWNER:  AF/XOR 

4.  ELEMENT  STAKEHOLOER(S):  SAF/AOX.  Air  Force  Acquisition  Executive  (AFAE),  Using 
Command.  AFMC,  AFOTEC,  AF/IN,  AFA.G.  Program  Executive  Officer  (PEO),  and  Project  Manager 
(PM). 

5.  REQUIREMENT:  SAF/AQ  Acquisition  Policy  90M-006,  Requirements  and  Acquisition  Program 
Review.  2  Sep  90,  directs  Summit  policy. 

6.  PURPOSE/OBJECnVES: 

a.  Purpose;  Assess  project  (ACAT I)  progress  in  meeting  user-stated  needs  and  requirements. 

b.  Objectives:  Ensure  the  Operational  Concept  is  complete;  confirm  funding  levels,  priorities, 
schedules,  direction,  management  efforts  are  adequate:  establish  realistic,  achievable,  and  affordable 
performance  and  support  goals;  and  resolve  major  operational  or  technical  issues  that  could  affect 
success  of  the  projed. 

7.  DESCRIPTION:  This  activity  begins  as  soon  as  preparations  forthe  Summit  are  complete  (B1 4); 

The  ORD  and  RCM  have  been  scrubbed,  critical  operational  requirements  have  gone  through  rigorous 
trade  studies  (cost,  schedule,  performance),  a  requirements  audit  trail  has  been  created  or  validated,  the 
COEA  and  ORD  have  been  approved  by  the  Air  Force  Chief  of  Staff  (CSAF),  and  a  Summit  briefing  has 
been  prepared.  After  the  Summit,  the  updated  COEA  and  ORD  are  used  by  the  Product  Center  to 
support  the  Acquisition  Strategy  Process  (059).  The  COEA  and  ORD  will  also  be  reviewed  by 
Secretariat  and  Headquarters-level  personnel  to  prepare  forthe  AFSARC  Review  (B21  and  E^).  The 
COEA  will  eventually  be  briefed  to  OSD/P A&E  prior  to  the  DAB  Review  (C29).  Finally,  the  project 
POM/BES  can  be  u^ated  (B18),  if  the  opportunity  exists,  with  any  new  information  since  the  previous 
POM/BES  update,  wNch  was  done  after  selection  of  the  preferred  alternative  by  the  Using  Command. 

The  Summit  is  a  senior  level  review  of  a  major  defense  acquisition  (ACAT  I).  The  CSAF,  AFAE,  or 
AF/XO  may  schedule  a  Summit.  It  is  chaired  by  CSAF.  The  CSAF  may  direct  reviews  of  ACAT  ll-tV 
projects  b^ed  on  recommendations  of  the  Operating,  Implementing,  arid  Supporting  Cmmands.  The 
meeting  is  usually  attended  by  the  AFAE,  respective  commanders  of  the  Using,  Implementing,  and 
Supporting  commands,  AFOTEC.  AF/XO,  AF/IN,  AF/LG,  the  respective  SAF/AQ  Mission  Area  Director, 
the  PEO,  PM  and  AF/XOR.  Other  interested  organizations  may  be  invited  depending  on  subject  matter. 

Members  must  consider  operational  concepts,  the  projected  threat,  and  the  capabilities  of  other 
supporting  systems  to  ensure  the  technical  solutions  under  development  meet  the  user's  objectives.  The 
requirements  review  and  scrub  at  this  Summit  have  a  greater  impact  on  the  success  of  the  program  than 
any  future  Summit. 

As  a  general  guide,  the  Summit  meeting  is  scheduled  at  least  180  days  prior  to  the  next  scheduled 
Defense  Acquisition  Board  (DAB)  review.  AF/XOR  (1)  provides  specific  briefing  time,  format,  and 
content,  (2)  schedules,  conducts,  and  administers  the  Summit,  (3)  records,  publishes  and  distributes 
CSAF  minutes,  decisions,  and  action  items,  and  (4)  serves  as  focal  point  for  all  issues  requiring 
resolution.  SAF/AOX  is  the  OPR  for  Summit  guidance  and  lessons  learned. 
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Outline  lor  a  typical  briefing; 


TOPIC 
Purpose 
Background 
Mission  (Strategy, 

Scenario,  CONOPs) 

Requeements  (Key  Para¬ 
meters  Audit  Trail) 

Test  Issues 
Current  Project  Status 
Trade-Off  Analyses 
(Options,  SMM) 

Recommendations  and 
Conclusions 

The  CSAF  must  be  convinced  that  requirements  are  operatbnaHy  justifiable  and  programmatically 
feasible  to  achieve.  The  CSAF  can  recommend  project  adjustments  and  restructure  to  the  AFAE.  CSAF 
also  directs  summit  closure  actions,  e.g.,  update  documents  (ORD,  RCM)  to  reflect  changes  approved  at 
the  Summit. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  A  final  briefing  to  the  Summit  four  stars  has  been  developed,  reviewed  and  approved 
at  subordinate  levels.  The  MNS,  ORD,  RCM,  COEA,  CONOPS,  TEMP,  and  APB  have  been  prepared. 
Other  preparatory  activity  has  been  accomplished  (B14). 

b.  Exit;  Summit  members  have  reviewed  the  project  to  their  satisfaction  and  CSAF  has  directed  a 
future  course  of  action. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Input;  A  final  briefing  to  the  Summit  four  stars  has  been  developed,  reviewed  and  approved  at 
subordinate  levels.  The  ORD  and  RCM  have  been  scrubbed  (B14). 

b.  Outputs;  Minutes  documenting  the  four  stars  recommmendations  and  action  items,  lessons 
learned  for  future  Summits,  an  updated  POM/BES  input  (B16),  an  updated  ORD,  and  an  s^iproved 
COEA. 

10.  KEY  REFERENCES:  In  addition  to  Required  document  (see  Paragraph  5); 

a.  AF1 10-601,  Mission  Needs  and  Operational  Requirements  Guidance  and  Procedures,  16  Feb  93, 
Paragraph  1.11,  provides  Summit  guidance. 

b.  SAF/AQ  Summit  Process  Guide,  4  May  92,  provides  a  process  for  planning  and  executing 
Summits. 

11.  MPLEMENTATION  TOOLS:  AFMC/XR  is  responsible  for  keeping  the  SAF/AQ  Summit  Process 
Guide.  They  also  keep  lessons  learned,  process  improvement  recommendations,  and  minutes  from 
previous  SurrwnHs. 

12.  PLANNING  GUIDANCE:  For  more  planning  guidance,  reference  the  predecessor  block  to  this 
activity.  Prepare  for  Requirements  Summit  (B14).  For  more  lessons  learned,  best  practices,  and  traps, 
reference  the  SAF/AQ  Summit  Process  Guide. 


BRIEFER 
AF/XOR 
AF/XOR,  User 
User 

User 

OTA  (Operational  Test  Agency) 

PM 

PM 

PM 


Nowtt 


a.  DURATION:  SummHs  can  take  anywhere  from  3  hours  to  3  days.  Duration  of  action  Kerns  win 
depeiKl  on  the  nature  of  the  «Kion. 

b.  CONSTRAINTS:  A  major  constraint  will  be  wortung  the  4-star  calendars  to  get  them  together  in 
one  room  at  the  same  time. 

c.  RESOURCES:  The  Summit  will  require  a  conference  room  large  enough  to  accommodate  the 
members  identified  above,  plus  supporting  personnel 

d.  LESSONS  LEARNED:  Concentrate  on  scrubbing  requirements  earfy  instead  of  preparing  charts. 
Prior  to  the  General  Officer  pre-briefs,  generate  firm,  justifiable  thresholds  for  the  key  parameters. 

Operational  requirements  should  be  stated  in  tenns  of  basic  operational  capabilities  and  be  directly 
traceable  to  an  operational  mission  need.  You  must  be  able  to  trace  the  roots  of  the  requirement  back  to 
the  CONORS. 

Ensure  the  testers  are  active  in  the  requirements  scrub.  At  three  Smmits,  specific  user  requirements 
were  found  to  be  impossible  to  achieve  or  test. 

e.  BEST  PRACTICES:  Use  standard  requirements  terminology  from  the  DOD  5000  series 
documerfis  for  terms  such  as  threshold  and  objective,  key  parameters,  critical  system  characteristic, 
system  capabilities  and  characteristics,  etc. 

Get  as  close  as  you  can  to  the  principals  to  find  out  what  issues  they  will  be  bringing  to  the  table. 

Review  scenarios  and  CONORS  early  in  the  process.  This  is  necessary  prior  to  scrubbing  the  RCM 
and  SMM.  A  clearly  defined  CONORS  and  well-scrubbed  RCM  and  SMM  are  critical  to  a  successful 
summit. 

Develop  realistic  thresholds,  objectives,  and  SMM  values.  This  is  important  since  these  will  be  the 
basis  for  making  trade-offs. 

Several  Action  Officer  and  Colonel-  level  (even  general  officer  level  depending  on  program)  reviews 
should  have  been  held  to  fully  define  the  CONORS,  scrub  requirements  and  review  the  associated 
acquisition  strategy.  These  reviews  are  important  and  can  take  up  to  6-8  weeks. 

SPO  should  identify  primary  cost/schedule  drivers  so  the  user  can  develop  appropriate  thresholds  for 
those  requirements. 

f.  TRAPS:  Do  not  focus  preparatory  meetings  on  briefing  preparation.  Action  officer  and  0-6  level 
meetings  should  focus  on  actually  scrubbing  requirements.  The.  briefing  will  be  easier  if  the 
requirements  are  sound. 

Do  not  use  General  Officer  reviews  to  scnjb  requirements  and  acquisition  strategy.  Do  this  in 
the  earfy  planrfing  meetings! 
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1.  ELEMENT:  B1 6.  TBS  12.4.5.4  (|FC  93-3) 

2.  ELEMENT  TITLE:  Update  Program  POM/BES  Ir^ 

3.  ELEMENT  OWNER:  Secretary  of  the  Air  Force  (SECAF) 

4.  ELEMENT  STAKEHOLOER<S):  Air  Force  Chief  of  Staff  (CSAF),  HQ  USAF  Directorate  of  Proems 
and  Evaluation  (AF/PE),  Air  Force  Comptroller  (SAF/FM),  O^ty  Chief  of  Staff  for  Plans  and 
Operations  (AF/XO),  Program  Element  Monitor  (PEM),  MAXOMs,  and  Project  Manager. 

5.  REQUIREMENT:  DoD  Directive  7045.14,  The  Planning,  PrograrTvning,  aiKl  Budget  System  (PPBS), 
22  May  84. 

6.  PURPOSeOBJECnVES: 

a.  Purpose:  The  purpose  of  the  activity  is  to  update  (or  create)  approved  Air  Force  financial 
planning  documentation.  For  a  specific  project  office,  the  Program  Obj^ve  Memorandum  (POM),  and 
(to  a  lesser  extent)  the  Budget  Estimate  Submission  (BES),  are  the  primary  opportunities  for  a  project 
office  to  submit  project/program  requirements  into  approv^  Air  Force  planning  documentation. 

b.  Objective:  The  objective  is  for  the  Air  Force  to  develop  a  comprehensive  and  integrated  plan 
which  supports  the  Defense  Planning  Guidance  (A1 ).  At  the  project  level,  it  should  be  the  objective  of 
the  proje^  office  to  get  the  program  financial  requirements  approved  at  the  earliest  opportunity  to 
prevent  schedule  delays  due  to  funding  availability. 

7.  DESCRIPTION: 

t  a.  National  security  policy,  as  documented  in  the  Defense  Planning  Guidance  (DPG),  provides 

guidance  to  the  Services  for  POM  development  around  Decerrfeer  in  the  odd-numbered  years .  This 
provides  the  SECDEPs  fiscally-constrained  guidance  on  policy,  strategy,  force  planning,  and  resource 
planning.  During  this  same  timeframe,  OSD  provides  the  POM  documentation  requirements,  the  POM 
Preparation  Instructions  (PPI),  to  the  ^rvices.  Based  on  this  information,  all  MAJCOMs,  Field 
Operating  Agencies,  and  Direct  Reporting  Units  provide  POM  inputs  to  the  Air  Staff.  The  subsequent  Air 
Staff  activities  are  the  subject  of  this  element. 

b.  The  development  of  the  POM  is  the  process  by  which  all  Air  Force  resources  required  to 
execute  OSD  Defense  Planning  Guidance  (Bkx^  A1 )  are  documented  and  validated.  [For  a  specific 
project,  the  POM  represents  an  opportunity  to  get  the  projected  resource  requirements  documented  in 
the  Program  Cost  Estimate  (e.g.,  D53)  approved.]  The  POM  is  used  to  update  the  planning  for  the  6 
years  contained  in  the  Future  Year  Defense  Program  (FYDP).  The  FYDP  is  the  official  DoD  data  base 
and  document  which  is  a  compilation  of  the  total  resources  (forces,  manpower,  and  dollars)  programmed 
for  DoD,  arranged  by  Major  Force  Program  (MFP)  and  appropriation.  The  FYDP  projects  6  years  for  all 
data  except  forces,  which  extend  an  additional  3  years.  After  OSD  adjustments  are  made  to  the  POM, 
the  Air  Force  is  allowed  to  update  and  reprice  the  programs  which  were  approved  .  This  is  documented 
in  the  Budget  Estimate  Submission  (BES),  which  emphasizes  the  first  2  years  of  the  FYDP,  and  converts 
the  program  oriented  format  of  the  POM  into  the  appropriation  categories.  The  BES  is  a  primary  input  to 
the  President's  budget  submission  to  Congress,  and  if  supported,  eventually  program  budget 
appropriations. 

c.  The  current  structure  for  the  Air  Force  corporate  review/screening  process  was  established  in 
1991 ,  with  the  creation  of  eight  Resource  Allocation  Teams  (RATs).  The  RATs  are  the  focal  points  for 
resource  issues  for  the  following  functional  areas:  Nuclear  Deterrence,  Power  Projection,  Global 
Mobility,  Space  and  CCCI,  Materiel  Support,  Personnel  Support,  Classified  Programs,  and  National 
Foreign  Intelligence  Programs.  The  HQ  USAF  Directorate  of  Programs  and  Evaluation  (AF/PE)  is  the 
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office  of  primary  responsibility  for  the  Resource  Allocation  Process.  ArK>ther  key  player  in  the  POM 
process  is  the  Program  Element  Monitor  (PEM),  ^t^ho  is  the  overall  focal  point  for  the  programs  within  his 
Program  Element.  The  PEM  is  responsible  tor  addressing  aN  issues  cortceming  his  programs.  In  short, 
since  every  Program  Element  (PE)  is  assigned  to  a  RAT,  the  PEM  must  interface  with  that  team  to 
ensure  his  PE  is  property  suppled. 

d.  The  Program  Objective  Memorandum;  In  the  faU  of  the  odd-numbered  years,  the  MAJCOMs 
provide  their  POM  proposals  to  HQ  USAF.  These  include  a  prioritized  list  of  disconnects  and  any  ‘new 
starts'  that  are  proposed.  The  RATs  convene,  and  with  the  support  of  the  functiortal  staffs,  SAF/FM  and 
AF/PE,  the  teams  review  and  evaluate  the  MAJCOM  inputs.  Based  on  the  POM  inputs,  the  RATs 
generate  program  options  for  presentation  to  the  Air  Force  Council,  CSAF,  and  SECAF  from  late 
January  until  early  March  (<^  the  even-numbered  years).  During  this  same  period,  the  players  update  the 
POMs  to  reflect  any  Cot\gressional  budget  activities,  the  President's  Budget  submission  to  Congress, 
OSD  budget  exercises  or  fiscal  guidance,  and  new  OSD  Defense  Planning  Guidance  or  Air  Force 
Planning  Guidance. 

e.  At  the  completion  of  the  POM  deliberations,  SAF/FM  verifies  the  pricing  of  the  approved 
options,  and  the  final  Air  Force  POM  is  documented  and  coordinated.  The  POM  is  submitted  to  OSD  on 
1  April  (A13)  and  at  this  time,  SAF/FM  updates  the  FYDP  to  reflect  the  Air  Force  approved  position.  At 
the  OSD  level,  any  SECOEF  decisions  to  adjust  the  Service  POMs  are  recorded  in  Program  Decision 
Memorandums  (PDMs). 

f.  The  Budget  Estimate  Submission;  The  first  step  in  the  BES  process  is  the  Air  Force  Summer 
Review.  SAF/FM  performs  the  Summer  Review,  which  consists  of  an  evaluation  of  the  pricing  and 
execution  of  the  Air  Force  investment  accounts.  Program  and  finarx:ial  information  from  this  review, 
plus  any  PDMs  issued  by  OSD,  and  any  necessary  repricing  of  elements  in  the  data  bases,  is  used  to 
develop  the  Air  Force  Budget  Estimate  Submission,  which  occurs  in  August/September.  Note;  While 
the  project  offices  can  expect  to  be  tasked  to  develop  program  documentation  to  support  budget 
requirements  in  the  BES  exercise,  normally  only  limited  (if  any)  adjustments  to  the  approved  Air  Force 
positfon  are  allowed. 

g.  At  this  time,  the  project  may  not  need  funding  tor  many  years,  but  if  funding  will  be  required 
in  any  of  the  years  addressed  in  the  POM,  it  is  essential  to  submit  the  financial  requirements  tor  the 
program.  The  project  office  must  establish  these  financial  rec^irements  in  Air  Force  planning  data  bases 
as  soon  as  possible  to  ensure  that  all  funding  is  available  to  support  execution  of  the  planned  program. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  POM  activities  in  the  field  start  in  toe  spring  of  toe  odd-numbered  years,  when 
the  Secretariat/ Air  Staff  provides  each  MAJCOM  with  the  dollar  and  resource  baselines  each  should  use 
to  derive  toe  MAJCOM  POM  packages.  In  the  summer.  AF/PE  publishes  the  POM  Preparation 
Instructions,  which  outlines  detailed  instructions  and  submission  schedules.  In  the  fall,  the  MAJCOM 
POM  inputs  (C27)  are  submitted  to  HQ  USAF.  The  MAJCOMs  are  tasked  to  generate  the  BES  in  mid¬ 
summer  of  the  even-numbered  years,  and  Air  Force  activity  starts  upon  receipt  of  the  MAJCOM  inputs 
(C27)  in  August-September. 

b.  Exit;  For  the  POM,  the  activity  is  completed  with  the  delivery  of  the  Air  Force 

POM  (in  both  hard  copy  and  computer  file)  to  OSD  (A13)  at  the  first  of  ^ril  in  the  even-numbered  years. 
For  the  BES,  the  activity  is  completed  with  the  submission  of  the  BES  to  OSD  in  mid-September  of  the 
even-numbered  years  (At  3). 
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9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs:  For  the  POM,  intormation  necessary  to  stait  this  activity  is  contained  in  the  Defense 
Planning  Guidance  (A1 ).  Air  Force  Planning  Guidance,  the  FYOP  and  the  MAJCOM  specific  baselines, 
and  the  POM  Planning  Instructions.  The  USAF  POM  re^'iew  process  requires  the  POM  subniissions 
(C27)  from  the  MAJCOMs.  For  the  BES,  results  of  the  Summer  Review,  and  the  receipt  of  Program 
Decision  Memorandums  frc-m  OSD  and  the  MAJCOM  BES  submissior>s  (C27)  are  necessary.  For  a 
individual  project,  if  a  Requirements  Summit  (B15)  has  been  convened,  the  results  should  be  a  useful 
input  to  the  USAF  review  process. 

b.  Outputs:  For  both  the  POM  and  the  BES.  the  output  is  the  delivery  of  the  Air  Force  approved 
documentation  to  OSD  (A13). 

10.  KEY  REFERENCES:  The  references  below  provide  more  specific  implementation  guidance: 

a.  AFP  172-4,  The  Air  Force  Budget  Process.  October  1987  -  Describes  the  Air  Force  budget 
process. 

b.  DoDI  7045.7,  Implementation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 
23  May  84  -  Describes  the  budget  process  within  the  Department  of  Defense. 

11.  IMPLEMENTATION  TOOLS;  "The  PPBS  Primer."  7th  Edition.  Jan  93.  This  document,  while  still 
"draft,"  is  published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and 
provides  a  valuable  description  of  the  current  PPBS  process.  This  is  one  of  the  few  documents  that 
describes  the  current  process,  and  it  does  so  in  detail.  Further,  it  defines  the  activity  schedule  for  the 
development  of  the  FY96  POM. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  After  receipt  of  the  MAJCOM  POM  inputs  in  the  fall.  Air  Force  worlts  POM 
iterations  through  the  following  March.  The  BES  activities  occur  from  August  through  mid-September, 
when  the  approved  documentation  is  delivered  to  OSD. 

b.  CONSTRAINTS:  The  primary  constraints  to  this  cK^tivity  are  the  resource  limitations  placed 
on  the  Air  Force  by  OSD,  and  the  schedule  limitations  on  management  reviews  inherent  in  the  budget 
timetable. 


c.  RESOURCES;  The  POM  deliberations  in  the  Air  Staff  require  intensive  activity  by  the 
Resource  Allocation  Teams.  AF/PE,  SAF/FM,  and  the  functional  staffs  to  reconcile  planning  objectives 
and  resources.  The  BES  generation  is  also  a  major  exercise,  but  is  more  limited,  since  it  represents  a 
financial  repackaging  of  the  approved  Air  Force  program. 

d.  LESSONS  LEARNED:  During  the  Air  Staff  POM  deliberations  and  reviews,  it  is  important 
that  the  project  manager  keeps  in  close  contact  with  the  project  representative(s)  in  AF/XO  (and 
SAF/AQ,  if  someone  has  been  identified).  This  is  important  to  help  resolve  issues  that  may  arise  and  to 
ensure  that  they  fully  understand  all  the  pertinent  aspects  of  the  project  and  can  defend  the  projected 
resource  requirements.  Also,  development  of  the  POM  is  a  comprehensive  and  complex  task,  and  the 
information  requested  can  be  expected  to  change  with  every  submission.  Therefore,  the  POM  preparer 
in  the  project  office  needs  to  ensure  that  (s)he  is  not  only  in  compliance  with  the  formal  tasking  and  the 
local  budget  staff  instmctions,  but  also  satisfies  the  information  and  documentation  needs  of  the  Air  Staff 
project  representative. 

e.  BEST  PRACTICES:  After  submission  of  the  POM  package,  the  project  office  should  posture 
itself  to  be  able  to  respond  effectively  to  programmatic  questions  and  be  able  to  generate  quantitative 
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answers  to  Air  Staff  requests  to  develop  and  price  out  program  variations  to  the  POM  submission.  The  I 

capability  to  generate  quality  "what-ir  information,  often  within  hours,  is  important,  since  the 
reconciliations  and  rankings  to  be  perfomned  by  the  Resource  Allocation  Teams  may  require 

modifications  to  the  MAJCOM  POM  requests  programs  in  terms  of  funding  levels,  quantities,  schedules.  * 

or  other  programmatic  aspects.  If  a  project  office  is  unable  to  provide  necessary  information  in  time  to 
support  the  decision  makers  the  project  may  not  be  supported,  or  may  be  approved  with  insufficient 
funding  levels. 

f.  TRAPS:  If  the  POM  is  the  first  for  the  project,  the  submission  will  be  considered  a  "New 
Start,”  and  identified  as  such.  There  may  be  additional  documentation  requirements  and  a  higher  level  R 

of  review  for  these  programs,  since  there  is  not  an  existing  funding  line.  Due  to  this,  the  project  office 
must  be  especially  prepared  to  defend  project  requirements. 
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1.  ELEMENT:  B1 7.  TBS  14.2.1. 1. 4.2.3  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  Acquisition  Strategy  Report  (ASR),  Request  for  Proposal  (RFP),  Source 
Selection  (SS)  Plan  and  approve  A^isition  Plan. 

3.  ELEMENT  OWNER(S):  Deputy  Assistarrt  Secretary  of  the  Air  Force  for  Contracting  (SAF/AQC). 

4.  ELEMENT  STAKEHOLOER(S):  Project/Program  Maruigers/Teams,  ASC/PK  (Contracting  Office), 
Buying  Office  Contracting  Official  (BOCO),  Program  Executive  Officers  (PEOs),  Operational  Users.  HQ 
AF/XO,  AFAE,  DAC,  ASC/CC,  and/or  PM  depending  on  ACAT  Level. 

5.  REQUIREI^NT:  The  requirement  for  this  review  was  established  by  Air  Force  Federal  Acquisition 
Regulation  Supplement  (AFFARS)  5307.103-90. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose: 

1)  To  allow  the  Air  Force  Acquisition  Executive  (AFAE)  the  opportunity  to  review  the 
Acquisition  Strategy  Report  (ASR)  and  the  proposed  request  for  proposal  (RFP)  for  ACAT  I  and  prXential 
ACAT  I  programs  prior  to  being  forwarded  to  the  USO(A)  for  final  review  and  approval. 

2)  After  the  USD(A)  review  the  purpose  is  review  the  Acquisition  Plan. 

b.  Objectives; 

1 )  To  allow  the  AFAE  the  opportunity  to  review  and  comment  on  the  ASR  and  RFP 
prior  to  being  reviewed  by  the  final  MOA  for  ACAT  I  programs. 

2)  To  obtain  an  AFAE  approved  Acquisition  Plan  following  the  USD(A)  review  and 
approval  of  the  ASR  and  proposed  RFP. 

7.  DESCRIPTION: 

a.  The  Acquisition  Strategy  Report  (ASR)(D58)  and  the  Acquisition  Plan  (D66)  are  developed 
by  the  project  team  using  the  collective  wisdom  and  guidance  of  senior  DoD  and  /Uxtuisition  through  the 
Integrated  Acquisition  Strategy  Process  (lASP).  The  Source  Selection  Plan  (D62)  is  created  by  the  RFP 
team  using  the  Streamlining  processes  created  and  maintained  by  ASC/CYX.  The  goal  is  to  have  these 
documents  reviewed  (and  in  the  case  of  the  ASR,  approved)  by  the  USD(A).  Enroute  to  the  USD(A) 
review,  the  project  will  be  required  to  navigate  through  a  gauntlet  of  prebriefs  culminating  with  SAF/AQ 
(B1 7).  Following  the  approval  of  the  Acquisition  Strategy  Report  and  a  favorable  review  of  the  RFP  and 
Source  Selection  plan  by  the  USD(A),  the  entire  package  is  returned  to  SAF/AQC,  who  will  then  provide 
it  to  the  AFAE  for  final  approval  of  the  Acquisition  Plan  (B17).  An  approved  Acquisition  Plan  is  required 
by  Federal  Acquisition  Regulations  (FARs)  prior  to  the  release  of  a  formal  Request  for  Proposal 
(RFP)(D69).  The  review  and  approval  of  these  documents  also  allow  the  project  team  to  begin 
preparation  of  the  functional  plans  and  remaining  milestone  documentation  (D60)  necessary  to  enter  into 
the  final  phase  of  the  lASP-the  Operational  Roundtable  (D67). 

b.  A  portion  of  the  ASC/PK  Policy  letter  92-040,  "Review,  Approval,  and  Authority  Summary,"  8 
Sep  92  provides  an  excellent  description  of  the  rules  and  reviews  concerning  Acquisition  Plans. 
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8.  ENTRANCE/EXIT  CRITERIA: 

a.  Erttrance  into  this  process  for  the  Air  Force  level  review  on  the  way  up  the  chain  occurs  when 
the  development  community  and  the  user  community  conte  together  on  the  i^an  of  attack  for 
project/program.  Once  this  is  accoiTV>lished,  you  can  put  together  an  Acquisition  Strategy  R^)ort  (D58). 
At  this  point  you  have  completed  the  majority  of  the  CE&D  technical  activities  arxf  are  focusing  on 
"packaging'  your  findings.  Entrance  criteria  for  erttering  the  AFAE  review  on  the  path  leading  back  down 
the  chain  to  the  development  community  have  been  met  when  the  USD(A)  approves  the  Acquisition 
Strategy  (At  5)  and  provides  a  favorable  review  of  the  RFP  and  Source  Sele^km  Plan<A1 5). 

b.  Exit  criteria  have  been  met  when  the  AFAE  approves  the  project  contracting  approach  for  the 
next  phase  of  the  program  which  will  allow  for  the  release  of  the  fonnal  RFP  (D69). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs; 

(1)  Acquisition  Strategy  Report  (ASR)  (DS8)-reviewed  and  approved  by  the  Acquisition 
Strategy  Panel  (ASP)  (D61). 

(2)  Request  for  Proposal  (RFP)  (as  required)-the  RFP  should  have  already  been 
through  a  Draft  RFP  process  and  be  ready  for  formal  release.  (D64). 

(3)  Acquisition  Plan-developed  with  inputs  from  the  ASP  approved  ASR  aixf  the  RFP 

(D66). 

(4)  Source  Selection  Plan-developed  by  the  RFP  team  (062). 

b.  Outputs:  SAF/AQ  approved  Acquisition  Plan  (B17)  -  which  will  allow  the  team  to  put  its 
proposal  on  the  street  arid  begin  the  formal  solicitation  process  (D69). 

10.  KEY  REFERENCES: 

a.  OoOl  5000.2,  Change  1,10  Mar  93. 

b.  OoD  5000.2  Manual,  Change  1,10  Mar  93. 

c.  ASC/PK  Policy  letter  92-040,  "Review,  Approval,  and  Authority  Summary,"  8  Sep  92 

d.  DRAFT  Air  Force  Supplement  1  to  DoDI  5000.2,  Aug  92 

e.  DSMC  Program  Manager's  Notebook,  Fact  Sheet  1 .6  (Jan  89) 

1 1 .  IMPLEMENTATION  TOOLS: 

a.  The  templates  contained  in  ASC/PK  Policy  letter  92-040,  "Review,  Approval,  and  Authority 
Summary,”  8  Sep  92  provide  an  excellent  review  of  the  Acquisition  Plan  routing  and  signature 
requirements  for  the  different  acquisition  types  and  categories.  At  this  point  in  the  acquisition  flow  only 
ACAT I  programs  or  potential  ACAT I  programs  are  considered.  (Non-DAB  programs  are  also  addressed 
in  this  policy  letter  arid  should  be  referenced  for  those  programs.). 

b.  The  ASC/YX  Integrated  process  flow  chart  and  the  associated  Process  guide  book  provide  an 
excellent  graphic  presentation  of  the  activities  which  lead  to  this  event  and  the  best  route  to  take. 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  actual  SAF/AQ  review  and  SAF/AQC  toHow-up  review  are  only  a  day  each. 

b.  CONSTRAINTS:  TIME  !  The  real-world  constrairtts  have  to  do  with  the  above-mentioned 
duration  and  timing  ~  lead-time  for  this  event  is  considerable.  If  you  use  the  ’hypothetical*  timeline 
included  in  the  constraint  block  for  A1 S  *USD(A)  Review”  you  will  be  in  good  sh£^}e  for  operating  wtthin 
your  constraints. 

c.  RESOURCES:  The  only  resource  required  is  a  knowledgeable  and  highly  poUshed  briefing 
team.  Be  sure  to  take  advantage  of  the  facilities  and  resources  available  for  the  development  of  the 
Acquisition  Plan  through  ASC/CYX.  The  functional  home  offices  may  be  able  to  provide  some  ’grey 
beard*  type  wisdom  as  well  as  some  additional  manpower  in  developing  your  Acquisition  Plan. 

d.  LESSONS  LEARNED:  Bubble-up  any  issues  and  concerns  that  arise  early  in  the 
development  of  the  Acquisit'  n  Plan  (for  example  .  during  the  ASP).  Don't  hide  the  ugly  things; 
eventually  all  the  dirty  laum  /  is  reviewed.  Try  to  have  an  Action  Officer  at  the  SAF/AQC  level  that  the 
team  can  use  as  a  sounding  board. 

e.  BEST  PRACTICES:  This  entire  process  was  designed  basically  to  prevent  a  large  break  in  a 
program  at  Milestone  II  while  they  prepared  the  solicitation  for  the  next  phase.  With  the 
’institutionalization’  of  this  process,  it  is  now  applicable  at  all  the  program  level  Milestones  (I,  II,  and  III). 
The  process  itself  is  a  best  practice.  It  is  a  less  formal  method  of  getting  a  ’heading  check’  on  the 
project/program  direction  without  generating  all  the  baggage  that  accompanies  a  full-up  Milestone 
review. 

(1 )  Do  not  view  this  review  as  another  hurdle  that  the  team  must  get  by  in  order  to 
continue  on  its  way.  Take  full  advantage  of  the  review  process.  A  ’No’  at  this  point  is  not  the  death  nail 
it  could  have  been  at  the  Milestone  review  level. 

(2)  The  earlier  the  project  team  engages  with  the  action  officers  at  the  SAF/AQ  and 
USD(A)  levels  the  better.  The  more  they  know  about  how  and  why  of  the  decisions  the  team  has  made, 
the  fewer  questions  there  will  be  remaining  unanswered.  This  review  process  is  an  excellerrt  opportunity 
to  build  a  constituency  -  don't  blow  this  opportunity. 

(3)  Make  the  SAF/AQ  Action  Officers  a  part  of  the  team  and  the  decision-making 

process. 

f.  TRAPS:  Failure  to  allow  enough  lead  time.  From  the  hypothetical  schedule  given  in 
constraints  area  of  block  At  5,  this  is  a  significant  event  and  requires  planning.  Recommerfo  this  activity 
be  addressed  during  the  development  of  the  Phase  I  plan  and  the  lASP  execution  plan  (D55). 
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1.  ELEMENT:  B1 9,  TBS  1.4.3. 1  (IFC93-3) 

2.  ELEMENT  TITLE:  Conduct  AFSARC/DAB  Planning  Meeting  (AF) 

3.  ELEMENT  OWNER(S):  SAF/AQXA 

4.  ELEMENT  STAKEHOLl)ER(S):  Operating  Command.  Product  Center,  Implenwnting  Command, 
and  PEO/OAC. 

5.  REQUIREMENT:  DoOl  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 ,  Part  13,  Sections  A  and  B.  Describes  the  requirements  and  timeframes  for  the  Planning  Meeting,  the 
Committee  Memo,  and  the  Master  Planning  Calendar. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  the  meeting  is  to  assess  prc^  progress  toward  satisfying  Phase  0 
exK  criteria  and  minimum  required  accornplishments  and  the  r^iness  of  the  project  to  proceed  into 
Phase  I.  An  Air  Force  Systems  Acquisition  Review  CouncH  (AFSARC)  will  be  held  for  Acquisition 
Category  (ACAT)  I  programs,  any  Joint  programs  for  wNch  the  Air  Force  is  lead,  and  ACAT  ll-IV 
programs  as  determined  by  the  Secretary  of  the  Air  Force  or  the  Air  Force  Acquisition  Executive  (AFAE). 
The  only  types  of  programs  that  usually  ^  not  go  to  the  AFSARC  but  directly  to  the  DAB  are  special 
access  programs  (i.e.,  the  B2  program).  For  additional  information  regarding  the  Office  of  the  Secretary 
of  Defense  (OSD)  DAB  Planning  Meeting,  refer  to  Data  Sheet  A23,  Conduct  DAB  Planning  Meeting. 

b.  Objectives:  Documentation  requirements  will  be  confirmed,  documentation  plans  will  be 
assessed,  and  a  detailed  schedule  of  preparations  set.  Issues  pertaining  to  the  exit  criteria  and  minimum 
required  accomplishments  arising  from  the  assessment  of  proj€^  progress  and  documentation  plans  will 
be  identified  and  documented  in  the  Committee  Memo  (also  known  as  Major  Issues  Guidance  (MIG) 
Memo). 

7.  DESCRIPTION: 

a.  The  AFSARC/Defense  Acquisition  Board  (DAB)  Milestone  Review  process  begins  with  a 
planning  meeting  held  at  least  180  days  prior  to  the  DAB  Milestone  Review.  There  will  be  only  one 
Planning  Meeting  held,  depe^ing  on  whether  the  acquisition  is  to  go  through  the  AFSARC  and  DAB  or 
AFSARC  only.  The  information  required  for  this  meeting  is  as  follows: 

(1)  Draft  Cost  Analysis  Requirements  Document  (CARD)  (D72) 

(2)  Proposed  Integrated  Program  Summary  (IPS)  Outline  (D68) 

(3)  Status  of  progress  toward  satisfying  exit  criteria  as  defined  in  the  Milestone  0 
Acquisition  Decision  Memorandum  (ADM) 

(4)  Status  of  progress  toward  satisfying  the  minimum  required  accomplishments  as 
defined  in  DoDI  5000.2,  Part  3,  Page  3-8 

(5)  Any  potential  issues 

(6)  Schedule  of  efforts  to  be  accomplished  to  get  to  the  DAB 

(7)  Project  status 

(8)  Status  of  all  documentatbn  needed  for  a  Milestone  I  decision,  based  on  the  specific 
ACAT  the  project  falls  under 
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b.  The  planning  meeting  is  chaired  by  the  relevant  AFSARC/DAB  Committee  Chair  (or  a 
represei^ive)  and  will  include  representatives  from  each  Committee  principal  and  the  DoD  Comportent. 
The  Project  Manager  may  attend  if  desired  by  the  Committee  Chair. 

c.  As  a  result  of  the  planning  meeting,  the  Committee  staff  specialist  prepares  a  Cotrvnittee 
Memo  tor  the  Committee  Chair's  signature  witoin  7  days  of  the  meeting.  This  memorandum  goes  to  the 
Under  Secretary  of  Defense  tor  Acquisition  and  to  the  AFAE  and  highlights  the  results  of  the  assessment 
of  project  progress,  and  contains  a  recommendation  as  to  whether  or  not  the  Milestone  Review  should  be 
held  as  planned.  It  also  kferttifies  issues  pertaining  to  the  exit  crrteria  and  minimum  required 
accoinplishmenis  that  Committee  members  reconvnended  be  addressed  in  the  project  documentation 
tor  Milestone  I  (066)  in  pr^ration  tor  the  Milestone  I  Documentation  Review  (B22).  Also,  as  a  result  of 
this  meeting,  the  CARO  will  be  forwarded  for  the  Component  Oxt  Analysis  effort  (B21 ). 

d.  The  Committee  staff  speaalist  also  prepares  a  master  planning  calendar  which  can  be  used 
as  a  management  tool  throughout  the  Committee  and  AFSARC/DAB  preparation  process.  This  calendar 
is  distribute  initialy  with  the  Committee  Memo  and  updated  and  redistributed  to  Office  of  the  Secretary 
of  Defense  and  DoD  Component  personnel  throughout  the  process. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  process  of  planning  tor  a  Committee  review  is  initiated  by  informal 
discussions  between  the  Office  of  the  Under  Secretary  of  Defense  for  Acquisition  and  DoD  Component 
personnel  and  by  refererKe  to  the  long-range  schedule  published  by  the  AFSARC  and  DAB  Executive 
Secretaries.  This  schedule  identifies  the  requirement  to  conduct  an  AFSARC/DAB  review  based  on 
project  schedule,  as  modified  by  actual  events  and  the  availability  of  the  participants. 

b.  Exit:  The  event  is  completed  upon  submission  of  the  Committee  Memo. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  Government  anci  Contractor  provide  project  status  information  (see  Para  7.a) 

Draft  CARD  (D72) 

Proposed  IPS  Outline  (D68) 

Draft  ORD  I  (Cl  9) 

Approved  Ac^isition  Strategy  (D68) 

b.  Outputs:  Major  Issues  Guidance  Memoranctom  (Committee  Memo) 

Master  Planning  Calendar 
Updated  CARD  for  CCA  (B21 ) 

10.  KEY  REFERENCES: 

a.  Air  Force  Acquisition  Model  (AFAM) 

b.  Draft  AF  Sup  1/DoDI  5000.2,  Aug  92,  Part  13A,  Atch  1,  Para  4.a.  Further  clarifies 
requirements  tor  AFSARC/DAB  Planning  Meeting. 

c.  PEM/Action  Officer  Handbook,  Apr  92,  Paragraph  B.4  and  subs.  Describes  the 
AFSARC/DAB  process. 

11.  IMPLEMENTATION  TOOLS:  None  identified. 


m 
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12.  PLANNMQ  GUIDANCE: 

a.  MIRATION:  Allow  lor  2  weeks  pre|>araftion  time  to  lest  the  waters*  lor  curreM  mood  of  the 
staff,  current  trends  in  direction/qi^ions.  and  to  gather  up-to-the-minute  current  status  on  the  project 
and  known  problems.  Attendance  is  atoout  one-half  day  in  or  outside  the  Pentagon.  FoHow-up  until  the 
Guidance  Memorandum  is  signed. 

b.  CONSTRAINTS: 

(1)  Lack  of  current  information  on  project  status 

(2)  Project  schedule  slippages 

(3)  Generating  a  review  schedule  that  can  be  supported  by  the  patties  involved 

c.  RESOURCES:  The  resources  should  include  a  conference  room  of  appropriate  size  to 
accommodate  the  number  of  attendees  for  the  Planning  Meeting,  an  operating  vu-graph  machine  and  a 
back-up.  an  individual  to  flip  the  charts  as  the  briefer  presents  his/her  charts,  and  a  secretary  taking 
notes  to  ensure  that  aH  comments,  questions,  changes,  etc.,  are  adequately  and  clearly  documented  for 
the  resultant  memo  that  wiH  be  issued  at  completion  of  the  meeting. 

d.  LESSONS  LEARNED: 

(1)  In  the  area  of  AFSARC/DAB  requirements,  taskings.  briefings,  and  other  associated 
events,  it  is  an  ab^lute  necessity  to  have  control  arid  authority  over  the  process.  It  is  imperative  that 
personrrel  working  AFSARC/DAB  issues  must  become  the  experts  and  be  proactive. 

(2)  Be  sure  the  purpose  of  the  AFSARC/DAB  is  clearly  defined  as  to  what  is  required  by 
the  Milestone  Decision  Authority  (MDA). 

(3)  Don't  go  to  the  Planning  Meeting  without  an  Operational  Requirements  Document 
(ORD).  documents  in  draft  form,  or  an  approved  acquisition  strategy. 

e.  BEST  PRACTICES: 

(1 )  Form  a  team  to  develop  a  strategy/plan  to  obtain  a  successful  AFSARC/DAB 
resolution.  This  team  should; 

(a)  Identify  requirements  for  a  Milestone  AFSARC/DAB. 

Create  and  track  briefings  to  support  DAB  requirements. 

(b)  Resolve/close  programmatic  issues  early. 

Identify  AFSARC/DAB  issues  and  recommerxf  solutions  to  SPO  director. 

(c)  Prepare  documentation  to  inckide  pre-coordination  with  the  OSD  staff,  the 
Air  Staff,  and  other  offices  as  appropriate. 

Write  and  track  AFSARC/DAB  documentation. 

(2)  The  F-22  SPO  formed  their  DAB  team  1 6  months  prior  to  their  Milestone  Decision. 
Their  team  had  three  objectives:  (1 )  develop  a  DAB  documentation  tracking  system,  (2)  identify  and 
resolve  issues/concems  that  could  affect  a  successful  Milestone  DAB  decision,  and  (3)  keep  the 
Program  Director  informed  on  all  issues.  Also,  based  on  the  timeline  identified  in  Section  13A  of  DoD 
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5000.2,  the  F-22  SPO  developed  an  internal  schedule  to  track  events/milestones  leading  up  to  the 
milestone  DAB  decision.  This  schedule  proved  to  be  an  invaluable  top-level  planning  tool  to  satisfy 
Milestone  requirements. 

(3)  Attendance  at  the  Planning  Meeting  by  the  Project  Director  is  not  required,  but  is 
allowed.  It  is  hic^ly  desirable  for  the  Project  Director  to  attend  because  he/she  has  the  knowledge  of  the 
kjH  breadth  of  the  program  and  may  be  able  to  answer  specific  questions  which  may  avoid  extensive 
written  explanations  on  a  'non  issue.’  Therefore,  it  is  recommended  that  the  Project  Director  coordinate 
with  i^ppropriate  parties  to  obtain  authorization  to  attend  planning  meetings. 

(4)  There  is  an  extremely  large  volume  of  point  papers,  briefing  charts  and  documents 
to  prepare.  The  Project  Director  should  identify  a  senior  (Lt  Col  or  GS/GM-14),  experienced  (preferably 
Level  III)  acquisition  manager  as  the  full  time  OPR  for  the  AFSARC/DAB  preparation  on  his/her  staff. 
That  individual  should  also  attend  the  Planning  Meeting,  if  invited,  and  establish  himseM/herself  with  the 
appropriate  action  officer  level  at  SAF  and  OSD.  He/she  rrujst  proactively  interact  with  those  action 
of^rs  as  the  AFSARC/DAB  process  proceeds. 

f.  TRAPS:  See  Lessons  Learned. 
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1.  ELEMENT:  B21 .  TBS  1 .4.4.0  (IFC  93-3) 

2.  ELEMENT  TITLE;  ConckKt  Component  Cost  Ani^ 

3.  ELEMENT  OWNERS:  Air  Force  Cost  Artalysis  Agency  (AFCAA) 

4.  ELEMENT  STAKEHOLOER(S):  Air  Force  Cost  Analysis  Agency  (AFCAA).  SAF/FMC.  ASD/PA&E 
(OSD),  Operating  and  Implefnenting  Commands,  Product  Center,  and  PEO  or  DAC. 

5.  REQUIREMENT: 

a.  DoDI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb  91 ,  Part  1 0. 
Section  A,  Para  3.b  and  c.  This  defines  requirement  for  component  cost  estimate. 

b.  Title  10.  United  States  Code.  Section  2434,  Independent  Cost  Estimates.  This  describes  the 
law  as  K  relates  to  the  CCA  and  is  implemented  by  DoDI  5000.2. 

6.  PURPOSeOBJECTIVES: 

a.  Purpose:  Provide  the  Milestone  Decision  Authority  (MDA)  with  an  independent  assessment 
of  the  proposed  project  cost. 

b.  Objectives: 

(1)  Test  the  reasonableness  of  Program  Office  Estimate  (POE). 

(2)  Provide  additional  cost  management  information  to  the  Air  Force  to  support  project 

decision  events. 

(3)  Increase  the  confidence  of  the  Air  Force  management,  OSD,  and  the  Congress  in 
the  cost  estimate  of  the  project. 

7.  DESCRIPTION: 

a.  The  AFCCA  financial  cost  team,  which  is  independent  of  the  project  office,  prepares  the  CCA 
estimates  to  test  the  reasonableness  of  all  project  costs,  regardless  of  fundi^  source  or  management 
control.  This  was  formerly  known  as  both  the  Independent  Cost  Estimate  (ICE),  and  the  Independent 
Cost  Analysis  (ICA).  The  scope  of  the  estimate  includes  the  project  as  currently  planned  and  all  cost 
categories,  i.e.,  investment,  appropriations,  test  and  evaluation,  procurement,  military  constniction, 
operation  and  maintenance,  and  military  personnel.  The  draft  CCA  covers  at  least  the  most  significant 
parts  of  the  estimate  to  the  degree  of  completeness  described  in  Part  1 0.  Para  2.c.  of  DoD  5000.2-M. 
The  project  office  must  plan  to  provide  the  POE  (D71 )  on  schedule  to  the  CCA  team.  The  timing  of  this 
estimate  is  outlined  in  the  CCA  plan.  The  plan  is  developed  by  the  CCA  team  with  coordination  by  the 
project  office.  The  project  office  is  also  required  to  document  and  provide  the  CARD  (D72)  information 
to  the  CCA  team  and  the  CAIG  (B23).  Members  of  the  CAIG  should  keep  in  contact  with  the  project 
office  to  resolve  issues  and  help  in  support  of  data  searches. 

b.  For  estimates  made  by  analogy  or  engineering  costing  techniques,  the  rationale  and 
procedures  used  to  prepare  such  estimates  must  be  documented. 

c.  The  CAIG  serves  as  the  Air  Force  group  tasked  to  review  the  Cost  Operational  Effectiveness 
Analysis  (COEA),  the  POE,  and  the  CCA. 
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d.  Actual  cost  experience  on  prototype  units,  early  engineering  development  hardware,  and 
early  production  hardware  for  the  project  un^r  consideration  should  be  used  to  the  maximum  extent 
possible.  When  cost  estimating  relationships  (CERs)  already  available  or  newly  developed  CERs  are 
used  to  make  the  cost  <}stimates,  the  specific  form  of  the  CER,  its  statistical  characteristics,  and  the 
assumptiorts  used  in  applying  the  CER  should  be  provided  to  the  CCA  team. 

e.  The  CCA  cost  and  technical  ^formation  is  input  from  the  CCA  through  the  CAIG  to  deveiope 
the  Service  cost  position  (SCP).  The  SCP  may  then  be  updated.  Information  from  the  Source  Selection 
(D70)  and  the  Requirements  Summit  (B1 5)  are  used  as  input  and  output  for  cost  and  technical 
background  information.  The  POE  (071 )  is  used  for  insight  into  program  cost  analysis  and  for  the  cost 
comparison  of  the  POE  to  the  CCA. 

f.  The  AFSARC/DAB  Planning  Meeting  (  B19)  irputs  scheduling  information  into  the  CCA  for 
planning  and  scheduling  purposes  since  the  CCA  data  is  used  in  the  AFSARC. 

g.  The  information  generated  in  the  POE  and  CCA  is  briefed  at  the  AF  CAIG  Review  (B23) 
which  assesses  the  validity  of  the  numbers.  The  POE  is  briefed  by  the  project  office  team  and  the  CCA 
is  briefed  by  the  CCA  team.  The  CCA  and  POE  are  then  refined  with  recommendations  from  the  CAIG. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Completion  of  the  CARD  (D72)  is  used  as  entrance  criteria.  The  data  in  the  CARD 
is  used  as  background  data  to  the  CCA. 

b.  Exit:  The  draft  CCA  will  be  provided  to  the  CAIG  (B23)  no  later  than  51  calendar  days  in 
advance  of  a  scheduled  DoD  Component  Milestone  or  project  review. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  The  information  from  the  CARD  (D72)  is  used  by  the  CCA  team  in  the  development 
of  the  CCA  report.  Cost  information  from  the  COEA  (B15)  and  assistance  from  the  project  office  in 
collecting  cost  information  (D71 )  are  needed  for  the  CCA  report. 

b.  Outputs;  The  CCA  data  is  input  into  the  CAIG  tor  development  of  the  Service  Cost  Position 
(SCP).  The  CAIG  discusses  the  CCA  data  and  their  findings  are  then  output  into  AFSARC  (B24).  This  is 
the  Air  Force  process  that  is  required  prior  to  a  Milestone  I  DAB  or  acts  as  the  Air  Force  approval 
process  for  non-DAB  projects/programs.  At  this  point  in  the  process,  since  there  has  not  been  a  program 
approval,  the  AFSARC  is  still  dealing  with  a  project  or  Phase  0  study  effort.  The  AFSARC  is  convened 
to  review  ACAT I  acquisition  projects  prior  to  any  Milestone  Decision  by  the  DAB  or  prior  to  a  program 
review  by  the  Secretary  of  Defense.  It  is  the  Air  Force  review  process  which  reviews  alt  program 
documentation  prior  to  going  to  the  DAB.  All  three  of  these  reviews  essentially  do  the  same  thing,  with 
different  levels  of  review  and  decision  makers  in  the  process.  They  review  all  the  program 
documentation  to  make  a  decision  for  program  go-ahead  or  continuance. 

10.  KEY  REFERENCES: 

a.  DoD7750.5-M,  Procedures  for  Management  of  Information  Requirements,  Nov  86. 
authorized  by  DoD  Directive  7750.5,  Management  and  Control  of  Information  Requirements.  7  Aug  86. 
This  relates  to  the  proper  procedures  for  handling  the  information  generated  in  the  CCA. 

b.  DoD  5000.2-M,  Defense  Acquisition  Management  Documentation  and  Reports,  23  Feb  91 , 
Part  1 5.  This  defines  procedures  for  the  preparation  and  submission  to  the  OSD  CAIG  of  cost  estimates 
prepared  in  support  of  DAB  committee  reviews  for  ACAT  I  D  programs,  and  in  support  of  DoD 
Cornponent  reviewers  of  ACAT  I  C  programs. 
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c.  OoD  5000.4,  OSO  Cost  Analysis  Impfovement  Group .  24  Nov  92.  Chapter  2.  Specifies  the 
responsibiities  and  functions  of  the  CAIG/CCA. 

11.  IMPLEMENTATION  TOOLS: 

a.  The  AFSC  Cost  Estimating  Handbook,  Volume  I,  Undated  -  Estimating  and  documentation 
information. 

b.  The  AFSC  Financial  Management  Handbook,  Nov  92  -  Update  fmancial  information. 

c.  AFMC  Cost  Estimating  Harxttook,  Volume  II.  Aeronautical .  21  Sep  92  -  Estimating  and 
documentation  information. 

1Z  PLANNING  GUIDANCE: 

a.  DURATION:  It  is  estimated  that  it  will  take  an  average  of  145  days  to  complete  a  CCA.  This 
is  from  starting  the  outline  to  presenting  it  to  the  Program  Element  Monitor  (PEM)  The  CCA  can  then  be 
updated  after  a  is  looked  at  in  the  CAIG  review. 


Days  before 

DAB 

145 

EVENT 

A  plan  outlining  the  CCA  will  be  submitted  to  the  CAIG. 

• 

118 

An  internal  mid-term  review  will  be  conducted  to  make  final  assessment  of  the 
methodology,  data,  and  CCA  plan. 

• 

62 

The  SPO  and  the  CCA  make  presentations  to  the  Program  Executive  Officer  (PEO). 

They  present  the  draft  CCA  and  POE. 

55 

Draft  cost  documentation  for  the  system  POE  and  CCA  are  provided  to  the  CAIG. 

55 

CAIG  "shirt  sleeve  review"  of  POE  and  CCA. 

• 

51 

SPO  and  the  CCA  team  will  present  estimates  to  the  CAIG. 

35 

CAIG  presents  SCP  to  OSD. 

b.  CONSTRAINTS:  The  CCA  is  tied  to  other  milestones  (see  inputs  and  outputs)  and  especially 
the  CARD  which  is  needed  180  days  before  the  DAB. 

c.  RESOURCES:  This  is  a  difficult  estimate  to  make;  it  varies  widely  depending  on  size  of  the 
project.  The  CCA  is  handled  at  AFCCA  in  Washington,  but  since  CARD  data  was  used  the  project  office 
may  need  to  answer  questions  concerning  the  CARD.  You  will  need  access  to  all  functional  areas  but 
will  need  a  full-time  FM  person  aixf  also  a  full  time  project  manager. 

d.  LESSONS  LEARNED:  There  are  two  lessons  teamed  in  the  Automated  Lessons  Learned 
Capture  and  Retrieval  System  (ALLCARS)  data  base  on  this  item.  The  syrtopsis  of  the  message  is; 

(1)  Take  all  Office  of  Secretary  of  Defense  Action  Officers  comments  (OSD/AO) 
seriously,  no  matter  how  painful. 

(2)  Advocate  a  DAB  OSD/AO  working  group  in  the  Pentagon. 
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•.  BEST  PRACTICES: 


(1)  Provide  the  CARD  on  time  so  the  DAB  wiN  not  sKp. 

(2)  Completing  the  CCA  2  months  prior  to  the  DAB  wW  ensure  the  Air  Force  CAIG  CCA 
Review  report  to  the  DAB,  and  Industries  Proposals  and  Source  Selectbn  have  time  to  digest  the  CCA 
report. 


(3)  Begin  early  to  track  details  of  the  POE  since  dHterences  wiN  need  to  be  explained 
during  this  process. 

f.  TRAPS:  A  must  to  this  activity  is  a  good  CARD  which  will  input  good  data  giving  a  much 
more  realistic  CCA.  If  data  is  not  accurate  and  complete  to  begin  with,  more  time  and  effort  will  be 
needed  to  perform  the  CCA. 
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1.  ELEMENT:  B22,  TBS  1. 4.6.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  Milestone  I  Documentation  (Air  Force) 

3.  ELEMENT  OWNER(S):  SAF/AQXA 
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4.  ELEMENT  STAKEHOLOER(S):  SAF  Functional  Offices,  Operating  Command,  Implementing 
Command,  OSD,  and  Product  Center. 

5.  REQUIREMENT: 

a.  DoDI  5000.2,  Defense  Acquisition  ManagemerM  Policies  and  Procedures,  23  Feb  91 ,  Part  13, 
Sections  A  and  B.  Describes  the  requirements,  time-frame,  arxl  attendees  for  the  Documentation 
Review. 

b.  SAF  Order  No.  20.6,  Establishment  of  the  Department  of  the  Air  Force  Systems  Acquisition 
Review  Council  (AFSARC),  23  Nov  81 .  This  defines  the  SAF  directed  roles  and  responsibilKies  of  the 
AFSARC. 

6.  PURPOSE/OBJECTIVES-. 

a.  Purpose;  The  AF  staff  documentation  review  serves  as  the  vehicle  for  identifying  and 
reviewing  major  questions  raised  by  the  draft  documentation,  arxf  any  new  developments  sirx:e  the 
planning  meeting  in  preparation  for  the  Air  Force  Systems  Acquisition  Review  Council  (AFSARC)  for 
Acquisition  Category  (ACAT)  I  programs,  any  Joint  program  for  which  the  Air  Force  is  the  lead,  and 
ACAT  ll-IV  programs  as  determined  by  the  Secretary  of  the  Air  Force  or  the  Air  Force  Acquisition 
Executive  (AFAE).  The  only  types  of  programs  that  usually  do  not  go  to  the  AFSARC  but  directly  to  the 
Defense  A^uisition  Board  (DAB)  are  special  access  programs  (i.e.,  the  B2  program). 

b.  Objectives:  To  ensure  that  issues  raised  during  the  Planning  Meeting  (B19)  are  addressed 
prior  to  submission  of  the  final  documents  (A19). 

7.  DESCRIPTION: 

a.  Prior  to  the  Air  Force  Documentation  Review,  the  Planning  Meeting  will  have  been  completed 
and  any  issues  documented  in  the  Committee  Memo  (B19).  Also,  a  list  of  the  milestone  documents  that 
will  be  required  for  the  Milestone  Decision  Authority  (MDA)  will  have  been  forwarded  to  the  Project 
Manager  along  with  any  issues  pertaining  to  those  documents  (D68).  The  Cost  &  Operational 
Effectiveness  Analysis  (COEA)  and  the  Operational  Requirements  Document  (ORD)  will  have  been 
reviewed  and  approved  for  ACAT  I  programs  at  the  Requirements  Summit  (B15)  and  forwarded  for 
inclusion  in  the  Documentation  Review. 

b.  The  AF  Documentation  Review  usually  consists  of  the  Program  Executive  Officer  (PEO), 
Program  Element  Monitor  (PEM),  appropriate  Air  Staff  functional  offices.  System  Program  Office 
(SPO),  Project  Manager,  representatives  from  Project  Office,  and  other  Service  Representatives  (if  Joint 
project).  It  is  held  approximately  14  calendar  days  before  an  AFSARC  review. 

c.  The  Project  Manager  begins  the  meeting  with  a  summary  briefing  covering  project  technical 
content  and  risks,  cost-effectiveness,  threat,  acquisition  strategy,  supportability  and  producibility.  test 
plans  and  results,  user  requirements,  and  a  status  update  since  the  AFSARC/DAB  Planning  Meeting 
(B19).  The  Project  Manager  should  answer  the  concerns  from  the  Planning  Meeting  during  the  review 
and  through  his/her  briefing.  For  ACAT  1C  projects  and  below,  the  documentation  slide  in  the  project 
briefing  must  say  each  document  has  been  completed.  For  ACAT  ID  projects,  the  documentation  status 
chart  in  the  project  briefing  does  not  have  to  say  completed  (final  documentation  due  10  days  after 
AFSARC  for  AFAE  approval).  (See  paragraph  9  for  a  list  of  required  documentation.) 
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d.  After  completing  the  review,  the  rr^  ults  are  documented  in  a  Committee  Memo  and  submitted 
within  5  working  days  to  the  AFAE.  The  Memo  will  identify  major  questions  not  answered  at  the 
Documerrtation  Review  and  any  major  deficiencies  and  issues  regarding  the  draft  milestone 
documerrtation,  and  issues  raised  since  the  planning  meeting.  The  Memo  may  also  delete  issues  from 
the  milestone  documentation  and  the  Project  Managers  briefing  at  the  Committee  Review,  if  it  was 
agreed  that  the  issue  had  been  resolved.  The  final  documents  for  ACAT  ID  projects,  adjusted  by  the 
Project  Manager  to  address  issues  identified  at  the  Documentation  Review,  must  be  submitted  not  later 
than  10  days  after  the  AFSARC  for  approval  by  the  AFAE  (A19).  For  ACAT  1C  projects  or  below,  all 
documentation  must  be  final  before  going  to  the  AFSARC  (B24). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  This  activity  begins  upon  receipt  of  draft  documentation  by  the  responsible 
functional  offices  within  the  Air  Staff  approximately  24  days  prior  to  the  planned  AFSARC  meeting.  It  is 
the  responsibility  of  the  PEM  or  Project  Manager  to  get  the  documents  to  the  right  office  in  the  Air  Staff 
for  review. 

b.  Exit;  The  results  of  the  Documentation  Review  meeting  are  documented  in  a  Committee 
Menx),  which  is  prepared  within  5  days  after  the  review.  Final,  updated  documents  must  be  submitted 
for  AFAE  approval  not  later  than  10  days  after  the  AFSARC. 

9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs;  The  following  documents  are  to  be  submitted  for  AFSARC  reviews; 
ACAIJ  ACAT  II.  III.  IV 


Operational  Requirements  Document  (ORD)  (B15) 
System  Threat  Assessment  Report  (STAR)  (A14) 

(STA) 

DIA  Intelligence  Report 
JROC  Assessment 

Integrated  Program  Summary  (IPS)  (D68) 

Integrated  Program  Assessment  (IPA) 

Program  Life  Cycle  Cost  Estimate  (PLCCE)  (D71 ) 
‘Acquisition  Program  Baseline  (APB)  D51 ) 

Integrated  Logistics  Support  Plan  (ILSP) 

‘Test  &  Evaluation  Master  Plan  (TEMP)  (D68) 
‘Component  Cost  Analysis  (CCA)  (A17) 

CCA  Report 

Cost  &  Operational  Effectiveness  Analysis  (COEA)  (B15) 
System  Concept  Paper  (SCP) 

Pollution  Prevention  Action  Plan  (D68) 

Program  Protection  Plan  (PPP)  (D68) 

Draft  Acquisition  Decision  Memorandum  (ADM) 

‘Required  by  Congress 


ORD 

System  Threat  Assessment 

Component  Intelligence  Report 

IPS 

IPA 

PLCCE 

‘APB 

ILSP 

‘TEMP 

‘CCA 

COEA 

SCP 


Draft  ADM 


b.  Outputs;  The  product  of  the  documentation  review  is  a  memorandum  to  the  AFAE  from  the 
Committee  Chair. 


» 


» 


10.  KEY  REFERENCES: 

a.  Air  Force  Acquisition  Model  (AFAM) 
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b.  PEM/Action  Officer  Handbook,  Apr  92,  Paragraph  B.4  and  subs.  Descri}es  the 
AFSARC/DAB  Process. 

c.  Draft  AF  Sup  1 ,  Aug  92,  to  DoDI  5000.2,  Part  13,  Section  A.  Shows  the  AFSARC/DAB 
planning  guideiines/checklist. 

11.  IMPLEMENTATION  TOOLS:  None  identified 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Preparation  tor  the  briefing  can  take  2  to  3  weeks,  with  several  people  creating 

charts. 


b.  CONSTRAINTS: 

(1 )  Inadequate  preparation  of  documentation 

(2)  Not  all  documents  submitted  on  time 

c.  RESOURCES:  The  resources  should  include  a  conference  room  of  appropriate  size  to 
accommodate  the  number  of  attendees  for  the  Documentation  Review,  an  operating  vu-graph  machine 
and  a  back-up,  an  individual  to  flip  the  charts  as  the  briefer  presents  his/her  charts,  and  a  secretary 
taking  notes  to  ensure  that  all  comments,  questions,  changes,  etc.,  are  adequately  and  clearly 
documented  for  the  resultant  memo  that  will  be  issued  upon  completion  of  the  review. 

d.  LESSONS  LEARNED: 

(1 )  At  the  earliest  possible  date,  ensure  with  the  reviewing  agency  that  there  is  an 
agreement  as  to  what  documentation  is  required. 

(2)  Be  prepared  to  assist  in  the  development  of,  guide  the  preparation  of,  research  the 
requirements  for,  and  review  of  all  documentation  for  the  AFSARC/DAB  to  ensure  accurate  and  timely 
completion. 


(3)  If  the  draft  documents  are  not  received  by  OSD  approximately  24  days  before  the 
review,  or  if  the  project  members  are  not  available  on  the  scheduled  date,  then  the  AFSARC  review  may 
have  to  be  postponed  until  the  documentation  status  is  determined.  It  is  imperative  that  the  Project 
Manager  have  his/her  people  begin  working  on  the  draft  documents  well  in  advance  of  the  scheduled 
AFSARC  review  to  ensure  that  they  meet  the  schedule  and  avoid  any  slips  in  the  overall  project 
schedule. 


e.  BEST  PRACTICES: 

(1 )  To  ensure  that  all  documentation  is  properly  prepared  in  accordance  with  OSD 
guidance/procedures  while  meeting  the  documentation  schedule,  individuals  within  the  SPO  should  be 
assigned  as  OPRs  for  AFSARC  documents.  Ultimately,  these  individuals  are  responsible  for  the  success 
or  failure  of  the  document  even  if  they  are  not  the  author.  The  OPR  should  identify  and  resolve  issues 
that  could  impact  the  document  completion  timeline. 

(2)  It  would  be  beneficial  to  the  prqect  to  identify  individuals  ouiside  the  project  office  to 
help  advise  and  coordinate  on  Milestone  AFSARC  issues/documentation.  This  relationship  would  prove 
beneficial  in  obtaining  a  quick  turnaround  on  AFSARC  documents  requiring  OSD-level  signatures, 
clarifying  OSD  and  Pentagon  issues/direction,  and  providing  information  to  the  project  office. 
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(3)  Have  the  AF  PEO  staff  obtain  recent  examples  of  Documentation  Review  briefings 
and  the  questions  of  the  various  staff  members.  With  good  ‘inter  and  a  little  ‘crystal  bair  speculation,  a 
single  added  chart  to  the  briefing  may  head  off  a  lengthy  discussion 

(4)  Close  liaison  with  the  Pentagon  action  officers  in  the  last  few  days  before  the 
documentation  review  can  produce  significant  results  to  the  Project  Manager.  Preliminary  comments 
from  the  committee  staff  will  be  forwarded  to  the  Air  Force  action  officers  as  the  staff  prepares  for  the 
meeting.  The  Project  Manager's  briefing  can  be  tailored  at  the  last  minute  to  adcfa’ess  any  known 
concerns.  Again,  work  close  with  the  action  officer  who  prepares  the  Committee  Memo  to  make  sure  it 
correctly  documents  closed  issues  and  focuses  in  on  a  narrower  scope  Committee  and  AFSARC  briefing. 
After  any  changes  are  made  to  the  briefing  charts  stemming  from  any  prebrief,  limit  any  additional 
changes  to  an  absolute  minimum  -  no  more  than  3  to  4  slides.  For  often,  just  before  the  AFSARC, 
people  start  to  get  'nervous*  and  SAF/AQXA  ends  up  with  a  new  briefing  while  the  read-ahead  to  the 
AFSARC  members  has  already  been  distributed  and  then  becomes  ‘overcome  by  events.‘  The 
briefings,  when  submitted,  should  be  able  to  stand  alone. 

f.  TRAPS:  See  Lessons  Learned. 
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Novn 


I 


I 


4.  ELEMENT  STAKEHOLOER(S):  Air  Force  Cost  Analysis  Agency  (AFCAA).  SAF/FM.  ASD/PA&E, 
Operating  and  Implementing  Commands.  Product  Center,  and  PEO  or  DAC. 

5.  REQUIREMENT: 

a.  DoDI  5000.2-M,  'Defense  Acquisition  Management  Documentation  and  Reports, *23  Feb  91 , 
Part  1 5,  defines  procedures  for  the  preparation  and  submission  to  the  Office  of  Secretary  of  Defense 
Cost  Analysis  Improvement  Group  for  cost  estimates  prepared  in  support  of  Defense  Acquisition  Board 
(DAB)  committee  reviews  for  Acquisition  Category  I  D  programs,  and  in  support  of  DoD  Component 
reviews  of  acquisition  Category  I  C  programs. 

b.  Title  to.  United  States  Code,  Section  2434,  Independent  Cost  Estimates;  10  Oct  86, 
Operational  Manpower  Requirements,  this  is  the  law  which  requires  the  CAIG. 

c.  DODO  5000.4,  OSD  Cost  Analysis  Improvement  Group.  24  Nov  92,  defines  CAIG 
responsibilities  and  procedures. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  CAIG  senres  as  the  Air  Force  group  tasked  to  review  the  Cost  and  Oper<r'f  <i)nal 
^  Effectiveness  Analysis  (COEA),  the  Program  Office  Estimate  (POE),  and  the  Component  Cost  Analysis 

(CCA).  (This  was  formerly  known  as  both  the  Independent  Cost  Estimate  (ICE),  and  the  Independent 
Cost  Analysis  (ICA).) 

b.  Objective:  The  CAIG  develops  the  Air  Force  Service  cost  position,  an  additional  estimate 
which  reflects  the  position  of  Secretary  of  the  Air  Force. 

7.  DESCRIPTION: 

a.  Preparation  for  the  Air  Force  CAIG  is  accomplished  through  both  planning  meetings  and 
status  reviews  which  are  convened  to  ensure  that  all  information  needed  during  the  formal  CAIG  review 
is  accomplished  on  schedule  and  with  the  rec^ired  quality.  The  Project  Office  must  plan  to  provide  the 
POE  analysis  on  a  schedule  which  is  dovetailed  with  the  Component  Cost  Analysis  (CCA)  (B21)  plan. 
The  Project  Office  is  also  required  to  document  and  provide  the  Cost  Analysis  Requirement  Description 
(CARD)  information  to  the  CCA  team  and  the  CAIG.  In  addition  to  the  formal  status  reviews,  members 
of  the  CAIG  should  keep  in  contact  with  the  estimating  team  to  resolve  issues  and  help  in  support  of  data 
searches.  No  later  than  55  days  before  the  formal  CAIG  review,  CAIG  representatives  perform  a  'shirt 
sleeve  review*  which  is  a  detailed  analysis  of  the  estimates  prior  to  the  CAIG.  The  shirt  sleeve  review 
should  take  a  minimum  of  1  day. 


» 


» 
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b.  In  the  beginning  of  the  formal  CAIG  briefing,  there  is  normally  a  program  overview  by  the 
project  manager.  ITie  project  manager  should  be  able  to  present  programmatic  aspects  of  the  project. 
The  COEA  is  reviewed  to  ensure  the  proper  decision  was  made  on  the  preferred  alternative,  and  the 
POE  of  the  preferred  altemative  is  presented  for  review,  followed  by  the  CCA.  If  all  questions  are  not 
answered  during  the  review,  follow-up  will  be  required  from  one  or  all  estimatirrg  teams.  At  the  end  of 
the  review  an  additional  estimate  is  developed  by  the  CAIG  which  represents  the  CAIG's  prelection  of 
program  costs.  This  is  called  the  Service  Cost  Position  (SCP),  and  is  submitted  to  the  Secretary  of  the 
Air  Force  for  approval.  After  this  review,  necessary  chartges  will  be  performed  to  the  CAIG  estimate 
prior  to  the  formal  CAIG  briefing.  After  the  approval,  the  CAIG  may  direct  the  COEA  to  be  updated  with 
the  SCP  values  and  reaccomplished  to  assure  the  COEA  outcome  doesnl  change.  The  output  of  the 
CAIG  will  be  reviewed  by  the  Air  Force  Systems  Acquiston  Review  Council  (AFSARC).  The  AFSARC 
(B24)  is  the  Air  Force  corporate  body  that  advises  the  AFAE  on  the  acquisition  of  major  systems.  There 
are  1 1  permanent  AFSARC  members  artd  3  advisors.  The  AFAE,  the  Assistant  Secretary  of  the  Air 
Force  (Acquisition),  chairs  the  AFSARC. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  When  the  AFSARC  scheduling  group  schedules  an  AFSARC,  it  starts  preliminary 
activities  on  the  CAIG.  Receipt  of  cost  documentation  is  needed  for  CAIG  review.  The  entrance  block 
will  be  the  Component  Cost  Analysis  which  is  B21 . 

b.  Exit:  Development  of  the  SCP  after  review  of  CCA  &  POE.  Data  from  this  block  will  go  into 
B24  for  AFSARC  review. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  CCA  (B21),  CARD,  POE  and  COEA  (048)  are  the  main  data  inputs. 

b.  Output:  The  output  is  the  Service  Cost  position,  which  gives  approval  to  submit  COEA,  CCA 
and  POE  to  the  AFSARC  (B24) 

10.  KEY  REFERENCES: 

a.  DoD  7750.5-M,  Procedures  for  Management  of  Information  Requirements,  Nov  86,  this  short 
regulation  defines  the  management  of  the  CAIG  information. 

b.  DoDI  5000.2,  Part  13,  Defense  a  :.juisition  Management  Policies  and  Procedures,  23  Feb  91 . 

11.  IMPLEMENTATION  TOOLS: 

a.  Air  Force  Acquisition  Model  (AFAM). 

b.  For  Cost  Estimating  documentation,  see  SAF/FM  "Cost  Estimating  Documentation  Checklist," 
16  Nov  92,  and  OSD  CAIG  "Operating  and  Support  Cost  Estimating  Guide,"  May  92. 
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12.  PLANNING  GUDANCE: 

a  DURATION:  A  typical  CAIG  briefing  will  last  around  2  hours;  1  day  for  prebrief.  DoDI 
5000.2,  Part  13,  Section  C,  provides  a  rough  agenda.  The  foliowing  is  a  timelirte  showing  the  ntajor 
events  precedirrg  an  AF  CAIG  review: 

Dayata^  Event 

AFCAIG 

Days  b^B  DAB 

152  An  Air  Force  CAIG  planning  meeting. 

145  A  plan  outlining  the  CCA  will  be  submitted  to  the  CAIG. 

1 18  A  mid-term  review  will  be  corxfucted  to  make  final  assessment  of  the  methodology, 

data,  and  CCA  plan. 

62  The  SPO  and  the  CCA  presentations  to  the  PEO. 

55  Draft  cost  documentation  for  the  system  POE  and  CCA  are  provided  to  the  CAIG. 

55  Shirt  sleeve  review  of  POE  and  CCA. 

51  SPO  and  CCA  team  will  present  their  estimates  to  the  CAIG. 

b.  CONSTRAINTS:  The  CAIG  CCA  review  is  tied  to  other  milestones  (see  Inputs  arxf  Outputs) 
and  especially  the  Cost  Analysis  Requirement  Desertion  (CARD)  which  is  needed  180  days  before  the 
DAB  to  start  the  CCA  activity. 

c.  RESOURCES:  At  least  one  analyst  should  be  assigned  to  monitor  CCA/POE/COEA 
activities  and  resolve  issues.  One  to  five  analysts  could  be  expected  to  work  the  project  as  a  primary 
duty  after  receipt  of  the  documentation  until  completion  of  the  SCP. 

d.  LESSONS  LEARNED:  There  are  no  lessons  learned  on  CAIG  CCA  review,  but  there  are  two 
#  applicable  lessons  learned  in  the  Automated  Lessons  Learned  Capture  and  Retrieval  System 

(ALLCARS)  data  base  on  CCA.  The  synopsis  of  the  message  is: 

(1)  Take  all  comments  of  Under  Secretary  of  Defense  Action  Officer  (USD/AO) 
seriously,  no  matter  how  painful. 

(2)  Set  up  a  DAB  OSD/OA  working  group  in  the  Pentagon. 

e.  BEST  PRACTICES:  When  the  DAB  is  scheduled,  the  project  office,  AFCAA,  AF  CAIG,  and 
OSD  CAIG  representatives  should  meet  as  soon  as  possible  to  ensure  that  the  estimate  to  be  presented 
to  the  CAIGs  will  satisfy  requirements  and  have  the  same  ground  rules,  assumptions,  scope,  etc. 

f.  TRAPS:  A  must  to  this  activity  is  a  good  CARD  that  will  provide  good  data  for  the  CCA  and 
POE  development.  Also,  if  data  is  accurate  and  complete,  less  time  and  manpower  wiH  be  needed  to 
develop  the  CCA  information  necessary  for  the  CAIG.  If  the  CARD  is  not  provided  on  time,  the  DAB 
may  slip. 
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1.  ELEICNT:  B24.  TBS  1 .4.7.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  Air  Force  Systems  Acquisition  Review  Counci  (AFSARC) 

3.  ELEMENT  OWNER(S):  Air  Force  Acquisition  Executive  (AFAE).  SAF/AQX 
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4.  ELEMENT  STAICEHOLOER(S):  Air  Force  Acquisiion  Executive<AFAE) ,  SAF/AQX,  Operating 
Command,  Implementing  Command,  Product  Centers,  PEO,  and  DAC. 

5.  REQUIREMENT: 

a.  SAF  Order  No.  20.6  ’Establishment  of  the  Department  of  the  Air  Force  Systems  Acquisiion 
Review  Council  (AFSARC),”23  Nov  81 .  This  defines  the  SAF  directed  roles  anti  responstotfties  of  the 
AFSARC. 

b.  SAF/AQ  Memorandum  for  AFSARC  members,  17  Apr  93.  This  covers  who  will  present 
information  to  the  AFSARC. 

c.  DoOl  5000.2,  Part  1 1 ,  Section  C.  This  delineates  the  documents  required  for  Milestone  Reviews. 

d.  AF  Sup  l/OoOl  5000.2  Part  13  Section  A,  Atch  1  Aug  92.  This  section  covers  the  basic  procedures 
that  the  AFSARC  will  follow. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  AFSARC  process  implements  DoOl  5000.2,  Section  1 1  -C,  for  AFAE  review  of 
ACAT I  programs,  any  Joint  program  for  which  the  Air  Force  is  the  lead,  and  ACAT  ll-IV  programs  as 
determined  by  the  Secretary  of  the  Air  Force  (SAF)  or  the  Air  Force  Ac^isition  Executive  (AFAE).  This 
block  describes  an  Air  Force  process  that  is  required  prior  to  a  Milestone  I  DAB  or  acts  as  the  Air  Force 
DAB  for  non-DAB  projects/programs.  At  this  point  in  the  process,  since  there  has  not  been  a  program 
decision,  the  AFSARC  is  still  dealing  with  a  project  or  Phase  0  study  effort.  The  AFSARC  will  be  dealing 
with  this  project  to  determine  if  it  should  become  a  program.  All  references  to  program  in  this  section  are 
generic  references  and  may  be  considered  potential  programs  or  study  projects.  The  AFSARC  is 
convened  to  review  ACAT  I  acquisition  programs  prior  to  any  milestone  decision  by  the  Defense 
Ac^isition  Board  (DAB)  or  prior  to  a  program  review  by  the  Secretary  of  Defense.  It  is  the  Air  Force 
review  process  which  reviews  aN  program  documentation  prior  to  going  to  the  DAB.  The  AFSARC 
functions  as  the  DAB  for  all  Air  Force  programs  that  are  less  than  ACAT  I. 

b.  Objective:  The  AFSARC  is  convened  to  review  ACAT  I  acquisition  programs  prior  to  a  mUestorte 
decision  or  prior  to  a  program  review  by  the  Secretary  of  Defense.  It  is  the  Air  Force  review  process 
which  reviews  all  program  documentation  prior  to  going  to  the  DAB.  The  AFSARC  is  held  for  all  Air 
Force  programs  that  are  less  than  ACAT  I  and  Service  managed  ACT  I  programs.  The  AFSARC  is  held 
in  addition  to  both  the  Summit  arKf  DAB  reviews.  AH  three  of  these  reviews  essentially  do  the  same 
thing;  they  review  all  the  program  documentation  to  make  a  recommendation  for  or  the  actual  decision 
for  program  go-ahead  or  continuance.  The  only  difference  between  the  three  is  the  level  of  review  and 
the  decision  auttxxity  of  the  participants.  Also,  Sumrrtits  are  not  always  held  and  are  not  necessary  at 
any  particular  time.  Therefore,  Summit  reviews  are  held  when  neccessary. 
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7.  DESCRIPTION: 

a.  TheAFSARCistheAirFofceoorporatebodythatadvisestheAFAEontheacquisilionof  miyor 
systems.  Tbeie  are  11  permanent  AFSARC  memb^  and  3  advisers. 

CbaiL  The  AFAE.  who  is  the  Assistant  Secretary  o(  the  Air  Force  (Acquisition),  chairs  the 
AFSARC. 

Members:  Assistant  Secretary  of  the  Air  Force  (Financial  Management  and  Comptroller) 

Assistant  Secretary  of  the  Air  Force  (Space) 

Assistant  Secretary  of  the  Air  Force  (Manpower,  Resen/e  Affairs,  Installations,  and 

EnvironmerN) 

Vice  Chief  of  Staff 

Deputy  Chief  of  Staff  (Personnel) 

De^ty  Chief  of  Staff  (Plans  and  Operatior>s) 

Deputy  Chief  of  Staff  (Lof^ics) 

Deputy  Chief  of  Staff  (Test  and  Evaluation) 

Director  of  Programs  and  Evaluation 

Commander,  Air  Force  Operational  Test  and  Evaluation  Center 

Commander,  Air  Force  Test  and  Evaluation 

Advisors:  General  Counsel 

Assistant  Chief  of  Staff  for  Intelligence 
Director  of  Strategic,  SOF  and  Airlift  Programs 

b.  The  AFSARC  also  has  an  Executive  Secretary  (SAF/AQX)  responsible  for  administrative  support 
to  the  AFSARC.  The  Executive  Secreta^  is  responsttrie  for  scheduHrig  AFSARC  meetings  and 
prebriefs,  publishing  the  AFSARC  planing  schedule,  ctistributing  read-ahead  material  to  the  Committee 
members,  publishing  AFSARC  meeting  agendas  and  approved  attendance  lists,  guidance  on  AFSARC 
policy  and  procedure,  and  coordinating  Air  Force  participation  in  the  DAB. 

c.  For  definition  purposes,  SAF/AQ  or  the  AF  orgaruzation  responsfele  for  the  Program  Element 
Monitor  (PEM)  function  is  designated  as  the  "Sponsoring  AFSARC  Member." 

d.  The  AFAE  may  convene  an  AFSARC  for  the  fottowing  reasons:  1 )  to  review  acquisition  programs 
prior  to  Milestone  Decisions  or  prior  to  Program  Review  by  the  Secretary  of  Defense  or  the  DAB;  2)  to 
review  programs  when  nominated  for  review  by  an  AFSARC  member  and  approved  by  the  AFAE;  3)  as 
requested  by  the  AFAE;  and  4)  as  directed  by  the  Secretary  of  the  Air  Force.  In  tNs  case  the  AFSARC  is 
convened  to  look  at  a  Phase  0  study  effort  to  determine  if  it  should  become  an  Air  Force  or  DoD 
program.  There  are  three  type  of  AFSARC  meetings  -  Milestone  Meeting,  Program  Review,  arxf 
PrincipNs  Meeting.  The  Milrctone  Meeting  is  discussed  here.  The  Prog^  Review  is  a  special  meeting 
caUed  by  the  AFSARC  when  they  deem  necessary  to  review  a  specific  program.  Details  of  that 
meeting  are  subject  to  the  needs  of  the  potential  program  or  project  review  at  the  time.  The  Principals 
Meeting  is  a  closed  door  session  of  the  members  only,  n  is  called  to  discuss  procedi’ras,  issues,  etc. 

e.  AFSARC  meetings  are  approved  by  the  AFAE.  Members  and  advisors  are  notified  of  meetings  by 
the  Executive  Secretary.  A  isting  of  all  planned  AFSARCs  is  published  every  4  months. 

f.  Mte^one  AFSARCs  wiil  only  be  waived  by  the  AFAE.  The  AFAE  is  the  decision  authority  for 
special  requirements,  operating  procedures,  and  abbreviation  or  waiver  of  documentation  requirements. 

g.  Procedures  -  For  potential  DAB  programs,  a  Joint  OSD-AF  planning  meeting  (Block  A23)  will  be 
held  approximately  6  months  before  the  planned  milestone.  This  will  be  scheduled  OSD.  At  this 
planning  meeting  the  project  director,  PEM  (if  there  has  been  one  assigned),  or  acting  PEM  should 
present  the  program  status,  propo^  IPS  outline  for  approval,  the  Cost  Analysis  Requirements 
Description  (CARD),  the  potential  issues  arxf  schedule  of  efforts  to  be  accomplished  prior  to  the 
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AFSARC.  In  accordance  with  OSD  CAIG  requirements  in  DoDO  5000.4,  the  program  wit  submit  a 
CARO  through  SAF/AQ  for  presentation  at  the  planning  meeting  (Block  B23). 

h.  Attendance.  Only  AFSARC  members  and  advisors  or  their  representatives  are  allowed  to  attend 
the  AFSARC.  Ottrar  attendees  are  at  the  written  invitation  of  the  AFAE.  Normally  the  pro(ect/pro^am 
manager  wiH  be  invited  to  brief  the  AFSARC.  The  sponsorng  AFSARC  member  wH  provide 
recommendations  for  other  attendees  to  the  Executive  Secretary  at  least  5  days  prior  to  the  AFSARC 
meeting. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  EntrarK^e; 

(1)  Prior  to  an  AFSARC,  all  necessary  documentation  must  be  prepared  (B22  and  B23).  The 
spon^ring  AFSARC  member  is  responsible  to  ensure  all  required  documentation  and  special  reports  are 
submitted  at  least  6  working  days  before  the  AFSARC. 

(2)  For  ACAT I  programs  the  AFSARC  is  rK>rmatly  held  5  weeks  before  the  DAB  review.  Other 
AFSARC  meetings  wiH  be  held  as  determined  by  the  AFAE.  However,  it  is  the  responsibility  of  the 
sponsoring  member  to  ensure  the  AFSARC  is  scheduled  for  those  programs  that  will  only  require  an 
AFSARC  (non-DAB  programs). 

b.  Exit:  For  non-DAB  programs  the  AFSARC  sponsoring  member  will  prepare  an  Acquisition 
Decision  Merrarandum  for  the  AFAE  signature  within  5  working  days.  For  DAB  programs  the  sponsorirrg 
AFSARC  member  will  update  the  IPS  to  include  AFSARC  findings,  coordinate  within  the  Air  Staff,  and 
provide  it  to  the  DAE  within  10  working  days  (B25,  A16,  A17,  and  A18). 


9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  The  documentation  requirements  for  an  AFSARC  are  the  same  as  for  the  upcoming 
Milestone  Review.  For  Milestone  I  these  are  (from  DODI  5000.2); 


ACAT.  I 

ORD 

STAR 

DIA  INTELLIGENCE  REPORT 
JROC  ASSESSMENT 
IPS 
IPA 

PLCCE 

APB  AGREEMENT 

ILSP 

TEMP 

CPSW 

ICE 

ICE  REPORT 

COEA 

ADM 


ACAT  II.IH.IV 

ORD 

STA 

COMPONENT  INTELLIGENCE  REPORT 

IPS 

IPA 

PLCCE 

APB  AGREEMENT 

ILSP 

TEMP 

ICE 

COEA 

ADM 


All  the  above  documentation  must  be  consistent  arxl  coordinated  within  the  appropriate  agencies 
prior  to  the  AFSARC.  As  some  of  these  are  living  documents,  the  best  available  data  is  recaiired.  Drafts 
are  acceptable  for  those  documents  that  are  approved  after  the  AFSARC  meets  (i.e.,TEMP).  See  block 
B22  Review  Milestone  I  Documents  (Air  Force). 
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b.  CXj^s;  The  output  of  the  AFSARC  is  either  an  ADM  for  non-DAB  (^rams  or.  for  DAB 
programs,  an  updated  IPS  that  goes  to  the  DAB  along  with  aH  the  other  required  documentation.  For 
non-DAB  programs,  the  sponsoring  member  will  prepare  an  Acquisition  Decision  MetTXjrandum  (ADM)  0 

through  the  AFSARC  Executive  Secretary,  for  signature  by  the  AFAE  within  5  working  days  after  the 
AFSARC  review.  For  DAB  programs,  the  sponsoring  member  will  update  the  IPS  to  include  AFSARC 
findings,  coordinate  within  the  Air  Staff,  and  provide  to  the  DAE  within  1 0  working  days. 

10.  KEY  REFERENCES: 

a.  SAF  Order  No.  20.6  "Establishment  of  the  Department  of  the  Air  Force  Systems  Acquisition  * 

Review  Council  (AFSARC). *23  Nov  81 ,  defines  the  SAF  directed  roles  and  responsibilities  of  the 

AFSARC. 

b.  SAF/AQ  Memorandum  for  AFSARC  members,  17  Apr  93,  covers  who  will  present  information  to 
the  AFSARC. 

c.  DoDI  5(X)0.2,  Part  1 1 ,  Section  C,  delineates  the  documents  required  for  Milestone  Reviews. 

d.  AF  Sup  1/DoDI  5000.2  Part  1 3,  Section  A,  Atch  1 ,  Aug  92,  covers  the  basic  procedures  that  the 
AFSARC  will  follow. 

e.  DoDI  5000.2,  Part  7,  Section  A,  describes  the  logistics  support  required.  • 

11.  IMPLEMENTATION  TOOLS:  AFSARC/DAB  Planning  Guidelines  summarize  the  steps  normally 
required  for  each  milestone.  Contact  SAF/AQX  for  this  document  (DSN  225-5973). 

12.  PLANNING  GUIDANCE:  The  AFSARC/DAB  Planning  Guidelines/Checklist  has  the  schedule  of 

events  that  are  required  prior  to  an  AFSARC.  Essentially  the  process  starts  6  to  7  months  prior  to  a  DAB  • 

with  an  AFSARC  planning  meeting  with  multiple  follow-up  meetings  and  reviews  prior  to  the  DAB.  See 
the  planning  guidance  for  detailed  information. 

a.  DURATION:  The  AFSARC/DAB  Planning  Guidelines  summarize  the  steps  normally  required  for 
each  milestone.  Contact  SAF/AQX  for  this  document. 

b.  CONSTRAINTS:  Major  constraint  for  the  AFSARC  is  getting  the  program  documentation  ready  * 

in  time  and  in  the  proper  format.  Another  constraint  is  the  briefing  itself.  This  normally  requires 

numerous  changes  and  practice  briefings.  Ensure  you  allow  sufficient  time  prior  to  the  actual  AFSARC 
meeting  to  get  all  the  pre-briefs  accomplished  (see  Section  e  Best  Practices). 

c.  RESOURCES:  All  functional  disciplines  must  be  involved  with  this  process.  The  number  of  ^ 

person  hours  required  varies  with  the  program  but  will  be  high.  There  are  no  special  security,  facility,  or 

computer  resources  required  other  than  those  normally  required  for  the  project  to  this  point. 

d.  LESSONS  LEARNED:  Contact  the  SAF/AQX  office  for  the  latest  guidance  on  lessons  learned. 

The  AFSARC  is  highly  dependent  on  the  politics  of  the  country,  the  current  administration,  the 
perceptions  of  the  leadership  in  DoD,  and  the  personalities  sitting  on  the  Council.  As  such  it  is 

imperative  that  the  program  office  contact  the  SAF/AQX  office  to  get  the  latest  guidance  prior  to  putting  * 

the  AFSARC  brief  together. 

e.  BEST  PRACTICES:  Prebrief  the  members  of  the  AFSARC  if  possible  but  at  a  minimum  prebrief 
their  staffs  to  get  any  show-stopper  questions  out  of  the  way  prior  to  the  actual  AFSARC. 

f.  TRAPS:  Not  using  the  current  briefing  format.  Not  having  all  the  data  required  by  the  numerous  * 

documents  required  for  the  AFSARC.  Not  being  totally  honest  and  aboveboard  with  not  only  your  good 

points  but  also  the  problems  you  anticipate. 
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1.  ELEKKNT:  B25.  TBS  1.4.12.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Write  and  Issue  Phase  I  PM D 

3.  ELEMENT  OWNER(S):  SAF/AQXA 

4.  ELEMENT  STAKEHOLOER(S):  AF/XOR,  Operating  Command.  Other  SAF/AO  4- Ltr  Offices. 

AF/IN.  Implementing  Command.  Product  Center.  PEO.  and  DAC. 

5.  REQUIREMENT:  AFR  800-1 .  Air  Force  Acquisition  System.  16  Feb  90.  Paragraph  3.a.  Defines  the 
requirement  and  point  of  contact  for  Program  Management  Directives  (PMD)s. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  the  PMD  is  to  direct  pro^ammatic  responsibilities  to  major 
command,  field,  and  test  organizations  for  systems  development,  modification,  or  acquisition  in  broad 
terms.  PMDs  originate  within  the  Headquarters  (Secretariat  and  Air  StafO  and  are  coordinated  with  all 
outside  implementing,  participating,  operating,  and  test  agencies. 

b.  Objectives:  The  intent  of  the  PMD  is  to  integrate  all  activities  which  affect  the  life  cycle  of  an 
acquisition.  All  Air  Force  acquisitions  are  required  to  have  a  complete  and  current  PMD. 

7.  DESCRIPTION: 

a.  Once  the  Milestone  Decision  Authority  (MDA)  makes  a  decision  to  proceed  with 
Demonstration/  Validation,  an  Acquisition  Decision  Memorandum  (ADM)  is  issued  in  accordance  with 
DoDI  5000.2,  Parts  1 1B  and  1 1C  (A22).  For  non-Defense  Acquisition  Board  (DAB)  programs,  the  Air 
Force  Systems  Acquisition  Review  Council  (AFSARC)  sponsoring  member  will  prepare  an  ADM  for  Air 
Force  A^isition  Executive  (AFAE)  signature  (B24).  Upon  receipt  of  the  ADM  from  the  MDA,  the 
appropriate  Air  Staff  Office  (e.g.,  SAF/AQX)  issues  a  PMD  to  the  assigned  lead  and  support  centers 
(AFMC)  which  clearly  identifies  the  user  requirement(s),  those  agencies  whose  efforts  are  required  for 
successful  completion  of  the  Phase  I  activities,  and  all  integration  responsibilities  related  to  the  primary 
system  being  discussed  (D75  and  D79).  PMDs  will  include  the  following  information: 

(1)  Assignment  of  Implementing,  Partic^ating,  Operating  Commands  and  Test  Agency. 

(2)  Identification  of  requirements  documents  (i.e..  Operational  Requirements  Document 
(ORD))  and  related  documents  (i.e..  Threat,  Defense  Planning  Guidance  (DPG),  etc.). 

(3)  Designation  of  the  Program  Executive  Officer  (PEO)/Designated  Acquisition 
Commander  (DAC)  who  is  responsible  for  the  project.  A  PEO  is  normally  designated  for  major 
programs.  A  DAC  is  normally  designated  for  less  than  major  programs.  Evaluation  of  programs  occurs 
on  an  annual  basis  to  determine  what  programs  are  consider^  major  programs.  OSD  releases  a  draft 
list  each  Spring  for  the  Sen/ices  to  review.  As  a  result  of  the  Services'  comments,  the  major  program  list 
is  finalized  and  released  by  OSD.  Because  PEOs  are  designated  for  specific  mission  areas,  and  DACs 
have  designated  areas  of  expertise,  most  programs  will  fall  within  a  particular  individual's  responsibility. 
Therefore,  it  is  possible  for  a  project  manager  to  determirre  the  applicable  PEO/DAC  even  prior  to  a 
PMD  being  released  by  determining  whether  or  not  an  effort  is  classified  a  major  program  and  then 
determining  who  is  responsbie  for  that  area. 


4r; 
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(4)  Provide  project  specific  information  such  as: 

(a)  Resource  priority  rating 

(b)  Additional  constraints  (beyond  those  in  MNS,  e.g.,  Nuclear  survivability) 

(c)  Authority  and  deviations 

(d)  Critical  interfaces  and  force  integration  issues 

(e)  Arms  Control  Treaty  verification 

(f)  Project  short  title 

(g)  Resources  (financial  and  rrranpower) 

The  above  information  may  or  may  not  apply  to  your  study  effort  or  project.  If  one  of  the  areas  does  not 
apply,  it  is  sufficient  to  include  the  heading  and  a  brief  statement  This  section  does  not  apply." 

(5)  Identify  funding  amount  and  source. 

(6)  Direct  development/update  of  required  program  plans. 

(7)  Identify  responsible  program  participaras. 

(8)  Identify  required  documentation  and  schedule  considerations  for  the  next  Milestone. 

(9)  Establish  review  and  coordination  procedures  for  next  milestone  decision. 

b.  If  the  decision  from  the  MDA  affects  any  programs  already  under  development,  then  the 
PEOs  or  Program  Element  Monitors  (PEMs)  who  are  responsibie  for  those  programs  leed  to  be  involved 
to  ensure  that  their  PMDs  are  chang^  to  support  ADM  tasks. 

c.  The  PMD  is  not  a  budgetary  document  and  provides  no  obligation  (funding)  authority. 
However,  a  PMD  will  not  be  issued  unless  the  project  has  planned  funding  or  prior  year  funding  which  is 
identified  in  the  President's  Budget  (PB)  and  Future  Years  Defense  Program  (FYDP),  plus  a  validated 
ORD. 


d.  The  PMD  is  coordinated  with  all  major  command  level  organizations  tasked  with  direction 
prior  to  being  coordinated  throughout  the  head^arters.  It  is  the  responsibility  of  the  originating  office  to 
ensure  full  and  complete  distribution  of  the  final  document  in  accordarx^  with  the  marxlatory  distribution 
list  in  SAF  Headquarters  Operating  Instroction  (HOI)  800-2,  Attachment  6.  In  addition  to  this  list,  the 
ori^nating  ofRce  creates  a  project  specific  distrfoution  list  for  organizations  listed  in  the  PMD.  At  the 
very  least,  this  list  will  be  comprised  of  the  Implementing  Command,  MDA.  Project  Director,  and  any 
headquarters  and  field  offices  tasked  in  the  PMD. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  This  activity  starts  with  the  issuance  of  an  ADM  by  the  MDA  (B24  and  A22). 

b.  Exit:  Issuance  of  the  PMD  to  the  appropriate  agencies  (D75  and  D79). 
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9.  KEY  INPUTS  Al«)  OUTPUTS: 

a.  inputs:  ADM  (A22  and  B24) 

b.  Outputs:  PMD  p75  and  079) 

10.  KEY  REFERENCES: 

a.  SAP  HOI  800-2,  Policy  and  Guidance  for  Preparing  Program  Management  Directives,  1  Jan 
93  (Still  in  Draft).  Deta^s  all  policy,  procedures,  and  documertation  requirements  for  completing  and 
coc^inating  PMDs  and  includes  sample  formats  for  the  various  types  of  PMDs. 

b.  Air  Force  Acquisition  Model  (AFAM) 

c.  Automated  Lessons  Learned  Capture  and  Retrieval  System  (ALLCARS) 

11.  IMPLEMENTATION  TOOLS:  None  identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  PMD  is  issued  upon  receipt  of  the  ADM.  Subsequent  PMDs  will  be  issued 
within  45  days  after  the  annual  submission  of  the  President's  Budget  (PB),  or  at  another  Milestone 
Decision. 

b.  CONSTRAINTS:  The  PMD  cannot  be  issued  unless  all  issues,  including  funding,  are 
resolved.  The  funding  approval  in  the  ADM  provides  the  funding  input  for  the  initial  PMD,  which  is 
current  at  the  time  the  PMD  is  issued. 

c.  RESOURCES:  It  takes  at  least  90  days  to  write/update,  coordinate,  and  issue  the  PMD.  This 
includes  40  working  days  for  coordination  with  outside  organizations. 

d.  LESSONS  LEARNED:  Loosely  written  or  generic  program  direction  for  initiative-type  efforts 
is  unacceptable.  The  Project  Manager  must  work  with  the  PEM  to  convince  him/her  to  establish  specific 
tasks  and  Milestones  within  the  PMD.  Accepting  PMD  or  other  direction  without  specific  .usks  and 
associated  Milestones  can  create  a  funding  dilemma. 

e.  BEST  PRACTICES: 

( 1 )  Close  coordination  between  the  acquisition  office,  the  user,  and  the  originating 
agency  while  writing  the  PMD  can  help  prevent  problems  later.  It  is  important  that  the  PMD  be  analyzed 
prior  to  release  in  order  to  identify  areas  of  responsibility,  appropriate  OPRs  and  to  determine 
executability  of  the  PMD. 

(2)  Direct  reference  to  functional  issues  in  program  directives  (ORD,  PMD,  etc.), 
program  strategy  documents  and  program  baselines  forces  attention  on  these  matters  early  in  the 
program  life  cycle.  This  allows  input  from  the  users  and  the  logistics  managers  in  the  earliest  stages 
possible  to  prevent  downstream  problems. 

f.  TRAPS:  A  poorly  written  or  inappropriate  PMD  can  direct  designs/solutions  or  program 
schedules  prematurely.  In  these  cases  the  acquisition  office  must  get  back  to  the  originating  agency  to 
reiieve/loosen  the  direction,  preferably  during  the  coordination  process. 


•  • 


§ 


D-163 


NowtS 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


t 


D-164 


1.  ELEMENT:  Cl.  TBS  0.14.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  Mission  Area  Assessment  (MAA) 

3.  ELEMENT  OWNER(S):  Operating  Commands,  Air  Staff 

4.  ELEMENT  STAKEHOLOER(S):  AF/XO.  Joint  Chiefs  of  Staff  (JCS),  and  Field  Operating  Agencies 
(FOAs). 

5.  REQUIREMENT:  DOD  Instruction  5000.2,  ‘Management  Policies  and  Procedures,*  Part  4, 
‘Requirements  Evolution  and  Affordability .‘  Section  B,  ‘Evolutionary  Requirements  Definition.* 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  To  identify  current  tasks  that  achieve  mission  objectives  required  to  support  the 
strategy  outlined  in  the  Defense  Planning  Guidance  (DPG). 

b.  Objectives:  By  utilizing  a  strategy-to-task  evaluation  process,  the  Air  Staff,  Operating 
Commands  and  FOAs  define  the  tasks  to  be  accomplished  by  Air  Force  assets  that  supp^  the  military 
strategy  provided  by  the  Chairman  of  the  Joint  Chiefs  of  Staff  (CXS)  and  the  Secretary  of  Defers 
(OSD).  The  Air  Force  conducts  annual  Mission  Area  Assessments  (MAAs)  on  selected  mission  areas. 

7.  DESCRIPTION:  The  CJCS's  military  strategy  is  outlined  in  the  National  Military  Strategy  (NMS) 
Document  and  the  Defense  Planning  Guidance,  with  the  Air  Force's  contribution  d^ment^  in  the  Air 
Force  Planning  Guidance.  The  Operating  Commands  and  FOAs  review  their  taskings,  assigned 
missions,  and  concept  of  operations  (CONOPS  -  C2)  for  the  various  regional  plans  that  assign  specific 
military  objectives  for  Air  Force  assets.  The  Operating  Commands  and  FOAs  continually  evaluate  these 
plans  and  JCS  guidance  for  changes  in  their  assigned  missions  and  objectives  that  may  have  an  impact 
on  tasks  that  must  be  accomplished  (C4,  C5).  The  outcome  of  the  MAA  is  used  as  a  resource  for 
subsequent  Air  Force  Planning  Guidance  publications.  The  following  step  is  to  perform  a  Mission  Need 
Analysis  (MNA)  to  determine  the  Operating  Command  or  FOA  capability  to  accomplish  the  assigned 
tasks  (C3,  C5).  The  Operating  Commands  and  FOAs  utilize  a  task-to-need  process  in  conducting  the 
MNA  to  evaluate  their  ability  to  accomplish  these  tasks  (C3,  C6). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrarrce:  Periodic  review  of  Air  Force  executive  guidance  as  contained  in  the  Air  Force 
Planning  Guidance  (B1) 

b.  Exit:  Mission  area  task  list  ready  for  Mission  Need  Analysis  (C3) 

9.  KEY  INPUTS/OUTPUTS: 


Squics 


National  Security  Strategy 
National  Military  Strategy 
Defense  Planning  Guidance 
Joint  Strategic  Capabilities  Plan 
Air  Force  Planning  Guidance 


President  (A1) 

CJCS(AI) 

CJCS(AI) 

CJCS  (A1) 

SAF,  CSAF  (B1) 


b.  Output  -  Operating  command  /  FOA  mission  task  list  published  in  the  Air  Force  Planning 
Guidance 


Nov  93 


10.  KEY  REFERENCES:  DOOl  5000.2.  Section  4B;  Air  Force  Instmction  10-601 .  "Mission  Needs 
Operational  Requirements  Guidance  and  Procedures,*  paragraph  1 .1 .3.  ’Mission  Area  Assessment.* 

11.  IMPLEMENTATION  TOOLS:  One  principal  source  for  the  strategy-to-task  breakdown  philosophy  is  * 

a  document  (title  unknown  at  this  time)  published  by  the  Rand  Corporation  and  authored  by  Gen  Glenn 

Kent  (USAF,  Retired). 

12.  PLANNING  GUK)ANCE: 

a.  DURATION:  Perkxlic  assessments  of  mission  rotes  and  capabilities  are  mt  entirely  new  to  the  R 

Air  Force,  although  the  *strategy-to-task*  hierarchy  is  a  recent  application  to  be  used  in  the  approach. 

Since  the  M AA  is  primarily  an  Operating  Commarid  responsibility,  the  framework  for  this  type  of  an 
approach  is  still  bemg  established  across  the  restructured  Operating  Commands,  where  experience  and 
background  are  fairly  limited.  A  nominal  timeframe  for  this  activity  is  2-3  months  for  execution. 

b.  CONSTRAINTS:  There  are  several  factors  that  have  an  influence  on  the  perceived 
importance  of  (and  support  to)  this  activity:  the  timing  of  the  most  recent  publication  of  the  OPG,  NMS 
and  AFPG;  the  relative  stability  of  the  perceived  threat,  national  strategy  and/or  Operating  Command 
operations;  and  the  level  of  effort(s)  being  devoted  to  identified  critical  mission  needs,  developed  from 
previous  years'  efforts. 

c.  RESOURCES:  Key  participants  or  players  in  this  effort  should  come  from  the  Operating 
Command  Planning,  Logistics,  Acquisition  arxf  other  functional  divisions.  Air  Staff  (i.e.,  USAF/XOR), 

FOA  Plans  and  Programs  Divisions,  and  Theater  Commands.  Support  may  be  requested  from  the 
Supporting  and  Irr^ementing  Commands  as  needed. 

d.  LESSONS  LEARNED: 

1 .  Each  Operating  Command  must  maintain  a  clear  and  consistent  perspective  of  the 
Department  of  Defense  mission  areas  and  respective  designators. 

2.  Must  be  careful  rx)t  to  identify  tasks  that  are  based  on  force  structure  or  its  capability,  which 
is  done  in  the  MNA. 

e.  BEST  PRACTICES:  Get  staff  inputs  to  planning  directorate  early  and  use  fbnnal  sessions  to 
document  the  MAA. 

f.  TRAPS:  The  content  of  the  DPG,  NMS  and  AFPG  guides  the  MAA  process.  Significant 
changes  in  national  strategy  or  interests  have  major  ripple  effects  throughout  the  MAJCOMs. 


*  •  •  ^  • 


D-166 


Nov  93 


1.  ELEMENT:  C-2JBS  0.1. 5.0  IFC  93-3 

2.  ELEMENT  TITLE:  Develop  Ckxtcflpi  of  Operations  (CONORS) 

3.  ELEMENT  OWNER(S):  Operating  MAJCOM 

4.  ELEMENT  STAKEHOLDER(S):  Theater  Commander-In-Chiefs  (CINCs),  HQ  USAF,  and 
Government,  industry  Studies  and  Analysis  Organizations. 

5.  REQUIREiyKNT:  OOD  Directive  5000.1,  Defense  Acquisition,  23  Feb  91 

6.  PURPOSE/OBJECnVES: 

a.  Purpose:  To  describe  the  Operating  Command  approach  (in  the  CONORS  document)  to  the 
deployment,  employment,  and  operation  of  a  new  or  upgraded  system  or  capability  that  they  are 
advocating  to  meet  identified  tasks  or  missions. 

b.  Objectives:  To  identify  and  document  the  operational  factors  in  a  CONORS  in  a  manner  that 
they  are: 

(1)  Considered  in  the  Mission  Need  Analysis  (MNA); 

(2)  Used  as  a  key  to  determining  the  Mission  Area  Assessment  (MAA); 

(3)  And,  eventually  become  the  core  for  the  Operational  Requirements  Document  (ORD)  and 
the  Cost  and  Operational  Effectiveness  Analysis  (COEA). 

7.  DESCRIPTION: 

a.  CONORS  describes  characteristics  and/or  capabilities  in  support  of  mission  need  analyses  and 
evolutionary  requirements  definition.  It  addresses  operational  structure,  capabilities,  employment, 
basing,  and  interoperability  of  operational  forces  systems  or  part  of  a  system.  This  concept  is  broad  in 
application  and  may  require  more  specific  description  in  follow-on  documents.  In  most  cases,  the 
CONORS  should  be  considered  in  the  MNA  and  eventually  becomes  an  integral  part  of  the  ORD  and 
COEA.  The  CONORS  is  also  a  key  document  used  In  preparation  for  the  Requirements  Summit. 

b.  Concept  development  normally  falls  into  two  broad  categories:  operational  and  system. 

(1)  An  operational  concept  involves  the  use,  employment,  and  deployment  of  military 
organizations,  operations,  or  fielcM  systems.  Operational  concept  documents  are  broad  in  scope  and 
provide  the  operating  MAJCOM  a  coordinated  position  to  aid  a  commander  in  understanding  a  particular 
mission  or  operational  area  application.  The  CONORS  can  significantly  impact  combat  capability.  The 
operational  concept  is  a  key  document  used  in  determining  the  MAA  and  MNA  in  the  Rre-Concept 
Exptoration  phase. 

(2)  A  system  oriented  concept  relates  directly  to  the  development  of  a  specific  system, 
component,  or  piece  of  equipment  arid  is  used  to  describe  the  need,  intended  use,  and  required  support 
as  the  system/equipment  progresses  through  the  acc^isition  cycle.  Concept  development  for  acquisition 
purposes  is  defined  by  AF1 10-601 ,  paragraph  1 .1 .8.  The  system  concept  will  evolve  from  the 
operational  concept  as  more  specific  information  becomes  available.  The  system  CONORS  will  be  used 
in  developing  the  ORD  in  the  Concept  Exploration  phase. 

c.  A  CONORS  is  an  integral  part  of  the  acquisition  program  documentation  process.  Draft  concepts 
normally  are  not  released  outside  the  Department  of  the  Air  Force  or  other  participating  Services  due  to 
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potential  source  selection  sensitivity  and  the  possibility  information  may  be  misinterpreted  or  changed. 
FoUowittg  its  approval  and  inclusion  of  recommended  revisions,  a  published  cortcept  document  may  be 
released  to  other  government  and  nongovernment  agencies  who  are  authorized  to  receive  such 
information  and  have  a  valid  need  to  know.  The  operating  MAXOM  also  has  the  option  to  have  industry 
assist  in  developing  the  CONORS.  Operating  MAJCOMs  must  clearly  state  the  constraints  they  want 
placed  on  the  review  and  distribution  of  a  concept  document.  Multi-command,  multi-Service,  arxf  Joint 
concept  document  initiatives  require  corKurrence  of  all  users  before  the  concept  document  is  released. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Work  can  begin  on  the  CONORS  as  soon  as  the  Air  Force  Planning  Guidance  (B1)  is 
received  from  the  Secretary  of  the  Air  Force  and  the  Air  Force  Chief  of  Staff. 

b.  Exit;  When  an  approved  CONORS  document  has  been  completed.  This  is  used  as  the  source  to 
conduct  deficiency  analyses  (C6)  for  the  purpose  of  identifying  capaility  needs  and  timing  using  task-to- 
need  methodology. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1 )  Review  Air  Force  Defense  Planning  (B1 ).  This  input  is  used  to  ensure  the  capabilities  and 
attributes  of  airpower  are  incorporated  into  various  strategy  documents,  e.g.,  CONORS. 

(2)  Corxfuct  Mission  Area  Assessment  (MAA)  (Cl).  The  MAJCOMs  and  Field  Operating 
Agencies  (FOAs)  .eview  taskings  and  update  assigned  missions  under  the  CONORS.  The  results  are 
subsequently  published  in  the  next  Air  Force  Planning  Guidance. 

(3)  Conduct  Mission  Need  Analyses  (MNA)  (C3).  If  a  nonmaterial  alternative  is  identified,  the 
CONORS  will  be  nxxlified. 

b.  Output;  Conduct  Deficiency  Analysis  (C6).  The  Operational  Command  is  responsible  for 
ensuring  that  Deficiency  Analyses  are  conducted  on  a  recurring  basis.  The  results  are  provided  back  to 
CONORS,  but  essentially  are  a  result  of  updates  to  the  CONORS.  Conduct  MAA  (C1)  may  be  revisited 
if  CONORS  changes  are  deemed  necessary  prior  to  release  to  C6. 

10.  KEY  REFERENCES:  AF1 10-601,  entitlied  "Oprational  Requirements,  Mission  Needs  and 
Operational  Requirements  Guidance  and  Procedures,"  16  Feb  93,  paragraph  1.1.8. 

11.  IMPLEMENTATION  TOOLS:  None  Identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  A  properly  coordinated  document  from  initial  assignment  to  approval  and 
publication  may  require  up  to  a  full  year  to  complete.  Such  factors  as  complexity,  level  of  coordination 
and  approval,  etc.,  determine  the  developmental  time  lines. 

b.  CONSTRAINTS:  Since  a  MAJCOM  Operating  Standard  for  devebping  the  CONORS  has  not 
been  published,  written  CONORS  pr^aration  instructions  and/or  guidance  is  unavailable. 

c.  RESOURCES:  HQ  AFMC  and  MAJCOMs  will  expend  approximately  45  to  135  days  (which 
equates  to  between  360  to  1080  hours)  to  draft,  finalize,  arxf  coordinate  the  CONORS.  This  time  is 
broken  down  as  follows:  (1 )  Work  to  be  accomplished  by  a  dedicated  action  officer  will  require  from  30 
to  120  days  (which  equate  to  between  240  to  960  hours)  and  (2)  Work  to  be  accomplished  by  three 
parttime  MAJCOM  individuals  for  approximately  7  days  (which  equates  to  approximately  120  hours). 
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d.  LESSONS  LEARNED:  The  MAJCOM  will  write  a  CONORS  prior  to  starti^  the  MNA  process 
because  CONORS  type  inputs  are  integral  to  the  "strategy-to-task*  proc^  explained  in  AF1 10-601 . 
History  reveals  that  this  effort  was  not  previously  impiernented  early  on  in  the  acquisition  process.  The 
'breaking  of  new  ground*  wMi  require  new  and  inrxjvative  approaches.  Since  the  CONORS  provides 
essential  inputs  to  the  MNA,  the  inability  to  est^lish  the  CONORS  assumptions  and  grounr^les  early, 
may  cause  the  MNA  identified  needs  and  deficiencies  to  become  suspect. 

0.  BEST  PRACTICES: 

(1 )  Define  in  broad  terms  the  operational  CONORS  early  to  form  the  basis  in  determining  the 
MAAandMNA. 

(2)  MAJCOMs  should  work  jointly  with  HQ  AFMC  to  ensure  the  user  concept  of  operations  has 
been  adequately  determined  and  defined. 

(3)  MAJCOM  should  develop  operational  CONORS  from  existing  CINC  war  planning  documents 
and  defense  planning  guidance.  MAJCOM  must  be  careful  not  to  include  any  system  concept  at  this 
point  in  time. 

The  system  CONORS  will  describe  the  intended  use  of  new  concepts  as  the  acquisition  process 
process  through  the  Concept  Exploration  phase. 

(4)  Operational  factors  form  the  core  of  the  CONORS  and  are  used  for  COEAand  ORDs. 
f.  TRAPS:  None  Identified. 
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1.  ELEMENT:  C3,  TBS  0.1. 7.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  Mission  Needs  Analysis  (MNA) 

3.  ELEMENT  OWNEI^S):  Operating  Command 

4.  ELEMENT  STAKEHOLOER(S):  Air  Staff.  MAJCOMs.  FOAs,  AFMC,  and  Waigamers  at  Service 
schools. 

5.  REQUIREMENT:  DODD  5000.1 ,  Defense  Acquisition  Management  Documentation  and  Reports,  Feb 
91 ,  Part  2B2.  This  directive  contains  the  requirements  generation  of  the  mission  needs. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  MNA  objective  is  to  evaluate  Air  Force  ability  to  accomplish  identified  tasks 
and  missions  using  current  and  programmed  forces.  This  process  is  c^led  Task-to-need.* 

b.  Objective;  To  identify  both  materiel  and  nonmateriel  alternatives  to  mission  needs. 

7.  DESCRIPTION: 

a.  The  MNA  process  evaluates  the  ability  of  current  and  programmed  forces  to  accomplish  the 
tasks  identified  during  the  mission  area  assessment  (MAA),  (Cl ).  The  result  is  a  list  of  potential 
shortfalls  or  needs,  (C6)  that  are  assessed  for  nonmateriel  alternatives,  (C7),  and  then,  if  none  are  found, 
fed  into  a  mission  needs  statement  (MNS),  (Cl 2).  M's  important  to  note  that  it  is  comnnon  to  have  a 
combination  of  both  materiel  and  nonmateriel  alternatives  for  the  same  shortfall.  The  MNA  assesses  the 
strengths  and  weaknesses  of  a  military  force  when  confronting  a  postulated  threat.  (C5),  in  a  specified 
scenario  or  set  of  circumstances  (such  as  force  structures,  geographic  location,  arid  envirorNnental 
conditions).  If  the  results  of  the  analysis  show  that  these  ^ces  are  adequate  to  accomplish  the  goals, 
no  further  analysis  is  necessary. 

(1 )  The  scenarios  should  include  a  set  based  on  situations  that  conform  to  the  scenarios 
in  the  Defense  Planning  Gkjidance  (DPG).  That  is,  the  underlying  analysis  assumptiorrs  concerning  the 
threat,  as  well  as  those  concerning  US  and  allied  involvement,  should  not  conflict  with  the  assumptions 
in  the  DPG  scenarios.  All  relevant  situations  in  the  DPG  scenarios  should  be  addressed  in  the  analysis. 
US  force  availability  should  be  consistent  with  any  deployment  or  reinforcement  objectives  included  in 
the  scenarios  or  established  elsewhere  in  the  DPG. 

(2)  Alternative  cases  may  be  considered  when  they  would  contribute  to  the  analysis,  in 
these  instances,  the  variance  from  the  DPG  scenarios  must  be  clearly  identified  and  addressed. 

(3)  Whatever  scenarios  are  selected,  the  MNA  must  show  how  current  or  kjture 
programmed  systems  would  contribute  to  accomplishment  of  MAA  tasks  or  a  national  military  mission 
established  by  the  DPG. 

b.  The  MAJCOMs  may  obtain  studies  arKf  analysis  support  from  various  agencies  (D4  and  D7). 
Regardless  of  the  source  of  the  analysis,  the  focus  remains  in  the  capability  to  accomplish  the  tasks.  If  a 
solution  involves  new  hardware  or  software  (a  materiel  solution),  the  mission  need  is  documented  in  a 
MNS.  If  a  nonmateriel  alternative  is  kfentifi^,  then  the  corKept  of  operations  has  to  be  modified  (C2). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  Completion  of  the  tasks  identified  during  the  Mission  Area  Assessment  (Cl ). 
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b.  Exit;  When  an  operational  Shortfall  or  malenei  need  is  identified. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs; 

(1)  During  mission  area  assessment  (MAA)  (C1 ).  tasks  have  been  idertifed  using  the 
strategy-to-task  framework. 

(2)  Develop  concept  of  operations  (CONORS),  (C2) 

(3)  Deterrr^  force  stmciure,  threat,  and  study  groundtules  and  assumptions,  Identify 
Study  Inputs  (C5). 

b.  Outputs; 

(1 )  If  a  nonmateriel  aHemative  (C7)  is  identified,  a  revisit  to  CONORS  is  recommended 
for  further  evaluation  (C2). 

(2)  When  a  materiel  need  is  identified,  a  MNS  (C12),  is  required. 

(3)  H,  after  the  deficiency  analysis  (C6),  an  operational  shortfall  is  not  kxind,  then  a 
review  of  the  mission  area  plans  (C4)  is  suggested. 

10.  KEY  REFERENCES: 

a.  AP1 1 0-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and  Rrocedures,  1 6  Feb 
93,  paragraphs  1 .1 .4  and  1.1.6,  the  planning  process  and  evolutionary  requirements  defirution. 

b.  AFR0 10-6,  Mission  Needs  and  Operational  Requirements,  19  Jan  93,  paragraph  1 .3, 
operational  requirements  to  assess  all  nonmateriel  solutions. 

c.  DOOl  5000.2,  Defense  Acquisition  Management  Rolicies  and  Rrocedures,  26  Feb  93,  Part  4, 
Section  E,  procedures  for  developing  the  mission  need  analysis. 

11.  IMPLEMENTATION  TOOLS:  None  identified 

12.  PLANMNG  GUIDANCE:  See  data  sheets  C6,  C7,  D4,  and  07  lor  more  details 

a.  DURATION:  Not  Identified. 

b.  CONSTRAINTS:  See  detail  data  sheets. 

c.  RESOURCES:  See  detail  data  sheets. 

d.  LESSONS  LEARNED:  See  detail  data  sheets. 

e.  BEST  PRACTICES:  Nonmateriel  altematives  should  be  examined  in  depth.  Too  often  the 
desire  for  a  materiei  solution  causes  a  superficial  exarnmatbn  of  nonmateriel  alternatives. 

f.  TRAPS:  See  detail  data  sheets. 
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3.  ELEMENT  OWNER(S):  Major  Commands  (MAJCOMs) 

4.  ELEMENT  STAKEHOLOER(S):  Operating  Commands  and  Implementing  Commands,  AFSAA,  HQ 
USAF/XO,  SAF/AQ,  Product  Cemers,  Logistic  Centers.  Service  SctKx>ls,  and  Industry. 

5.  REQUIREMENT:  0001 5000.1 .  Oefense  Acquisition,  23  Feb  91 ,  Part  1 ,  Para  A.1 .  This  directive 
provides  the  general  framework  for  Operational  involvement  in  stating  mission  needs  and  obtaining 
affordable  programs  which  is  the  basis  of  reviewing  mission  area  plans. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  activity  is  to  erasure  that  adequate  resources  (people  and  money) 
are  available  to  support  the  mission  area  planning  process. 

b.  Objective:  It  is  during  this  activity  that  the  MAJCOM  detemknes  vrhat  mission  area  ptanrung  will 
be  required,  which  agencies/organizations  need  to  be  involved  in  the  mission  area  planning  process  and 
what  funding  is  needed  to  support  any  study  arKf  analysis  effort. 

7.  DESCRIPTION:  In  preparation  for  mission  area  planning,  a  number  of  activities  are  occurring 
concurrently  within  a  Major  Command  (MAJCOM).  As  a  result,  there  are  several  action  officers  assigned 
within  the  Command  to  support  these  activities.  These  activities  include  two  approaches  to  the 
requiremerrts  process.  The  first  approach,  Technology  push,*  is  where  the  user  identifies  a  requirement 
based  on  a  technological  opportunity.  The  second  approach,  'requirements  pull,*  arises  from  any  source 
when  a  deficiency  or  problem  is  known  but  the  solution  is  unclear.  Both  of  these  c^jproaches  are 
supported  by  activities  of  the  Technical  Planning  Integrated  Product  Teams  (TPIPTs),  of  which  the 
MAJCOM  is  an  essential  player.  Other  activities  include  the  identification  of  any  necessary  support 
(dollars  and  people)  to  accomplish  the  mission  area  planning  activities.  Resources  can  be  drawn  from 
inside  the  Command  as  well  as  from  other  DoO  agencies  and  industry.  Finally,  the  MAJCOM  defines  the 
need  for  any  advisory  groups  necessary  to  oversee  the  mission  planning  and  requirements  activities. 

The  Study  Advisory  Group  (SAG),  which  is  a  senior  advisory  group  comprised  of  experienced  personnel 
from  different  Commands,  performs  this  necessary  function.  Each  of  these  activities  (technok^  push, 
requirements  pull,  TPIPT  involvement,  support  identification,  and  SAG  support)  is  described  below. 
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In  the  technology  push  approach,  MAJCOM  requirements  are  kfentified  based  upon  technology  which  is 
available  to  support  mission  needs  (D5).  This  technological  availability  can  be  existing  technology  that 
has  been  developed  by  the  DoD  laboratories  or  industry.  However,  technology  can  also  be  developed  to 
solve  user  deficiencies  through  TPIPT  activities  by  focusing  funding  within  industry  and  the  government 
laboratories  to  address  user  needed  technology  versus  other  projects  (D3).  During  this  activity,  action 
officers  are  assigned  to  oversee  these  activities. 


The  requirements  pull  process  resutts  from  the  mission  area  assessment  (C1)  and  mission  need  analysis 
(C3).  It  begins  when  the  Air  Force  planning  guidance  is  identified  in  the  Defense  Planning  Guide  (Bk^ 
A1)  and  in  the  Air  Force  Regional  Plans  (B1 )  and  supports  deficiency  analysis  (C6).  During  this  activity, 
action  officers  are  assigned  to  oversee  these  activities  and  frequently  industry  is  tasked  to  conduct 
studies  and  analyses  (D3). 
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TPIPT  Involvement 

TPIPTs  are  networks  of  experts  from  the  Implementing  and  Operational  Commands  who  plan  and 
facilitate  the  transition  of  technical  solutions  to  users'  long-term  operational  needs.  TPIPTs  faciUtate  the 
initial  planning  and  developmeitt  leading  to  technically  superior  solutions  to  both  the  long-and  short-term 
operational  needs  of  the  users.  A  typical  TPIPT  should  consist  of  a  network  of  development  planners. 
Operational  Command  users,  techriology  planners  from  Air  Force  laboratories,  logistics  center  planners, 
system  engineers,  and  representatives  from  test  organizations,  program  offices,  and  intelligence 
agencies.  TPIPTs  are  organized  by  mission  or  functional  area  to  gather,  analyze,  coordinate,  and 
disseminate  information  in  each  Air  Force  mission  area.  Each  product,  logistics,  and  test  center  may 
have  several  TPIPTs  organized  according  to  applicable  mission  areas  and  led  by  development  planners 
in  XR. 

The  objective  of  the  TPIPT  is  to  provide  development  planning  support  for  users  through  the 
development  of  road  maps  and  investment  recommeridations  for  all  Air  Force  mission  areas.  TPIPTs 
will  gather,  organize,  analyze,  and  disseminate  information  relating  user  requirements  to  technology 
development  and  transition  for  current  and  future  systems  and  for  support  infrastructure. 

Each  TPIPT  will  be  assigned  specific  functional  or  mission  areas  of  responsibility  and  will  provide  to 
decision  makers  an  integrated  20-year  mission  area  system-technology  roadmap  to  include  a  proposed 
investment  strategy.  Each  TPIPT  will  also  serve  as  the  functional  area  focal  point  for  urgent  user  needs. 
The  responsbilities  of  the  TPIPT  include; 

-  Conducting  or  identifying  required  analyses  to  assist  the  users  in  developing  strategic  plans  to 
meet  their  needs. 

-  Gathering,  assessing,  organizing,  and  disseminating  information  on  technology  available  from 
other  Services,  other  government  organizations,  irxJustry,  and  foreign  governments. 

-  Assessing  test  capabilities  within  each  mission  area. 

-  Assisting  program  offices  with  techmlogy  transition  planning  throughout  the  entire  system  life 

cycle. 


•  Assisting  in  the  planning  of  technology  investments  for  products,  materiel,  industrial  base 
infrastructure,  and  application  of  technology  to  fielded  systems. 

-  Defining  needed  intelligence  products  focused  to  support  research  planning  efforts. 

-  Developing  and  using  effective  metrics  to  measure  the  quality  of  the  technology  transition 
processes. 

In  fulfilling  their  overall  purpose,  the  TPIPTs  will  perform  the  following  functions: 

-  Provide  system-technology  road  maps. 

-  Promote  the  flow  of  information. 

-  Assist  in  technology  development  planning. 

-  Asset  in  technology  transition  planning. 

-  Recommended  analysis  and  evaluation  tasks. 
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-  Assist  users  in  conducting  Mission  Area  Assessments  (MAAs)  and  Cost  and  Operational 
EffectWe  Analyses  (COEAs) 

-  Ensure  ttevelopment  and  maintenance  of  databases  to  support  the  system-technology  road 
aps. 

TPIPT  Products: 

-  Technology  Investment  Recommendation  Report  (TIRR). 

-  Mission  Area  Development  Road  map  (MAOR)-Appendix  to  Air  MobUity  Master  Plan. 

Product  Center  XRs  wW  act  as  TPIPT  facilitators  by  developing  a  coorctinaied  TPIPT  charter  that 
describes  the  operations  and  functions  of  all  TPIPT  members  and  their  relationship  with  other  center 
organizations,  other  TPIPTs,  and  other  external  organizations.  AFMC/XR  is  the  OPR  for  TPIPTs  and  will 
publish  guidance  as  required. 

As  of  29  May  92,  TPIPTs  have  been  established  at  four  Product  Centers:  ASC,  HSC,  ESC,  and  SMC. 
The  following  TPIPTs  have  been  established  at  ASC:  Air  Superiority.  Air-to-Surface,  Special  Ops 
Forces.  Mobility,  and  Training. 

SuDoon  Identification 

During  this  activity,  the  MAJCOM  must  determine  what  mission  area  analyses  will  be  required,  when 
they  will  be  accomplished,  who  will  accompUsh  the  analyses  (internal  resources,  the  TPIPT  team, 
mdustry,  the  laboratories.  Product  Centers  or  Logistics  Centers,  and/or  the  Air  Force  Study  Board),  and 
what  funding  will  be  required  to  support  needed  studies  and  analyses. 

The  MAXOM  may  request  study  and  analysis  support  from  various  outside  resources  to  aid  them  in 
evaluating  their  ability  to  accomplish  required  mission  tasks.  In  Aeronautical  Systems  Center, 
Development  Planning  (ASC/XR)  is  responsible  for  performing  any  required  studies  and  analyses  in 
support  of  a  MAJCOM  for  these  pre-  Milestone  0  activities.  However.  XR  may  request  suppr^  from  any 
of  the  laboratories  or  existing  SPOs.  Outside  resources  may  also  become  involved  based  on  their 
initiatives  (versus  request  for  support  from  the  MAJCOM.)  For  instance,  a  laboratory  may  develop  a  new 
technology.  Sharing  this  technology  wfth  the  Using  Command  may  result  in  the  Using  Command 
generating  a  mission  need  statement  (MNS)  and/or  a  request  for  PE  65808  fund^  for  studies  and 
analyses.  Attematively,  industry  may  approach  a  laboratory  or  the  Using  Command  with  a  new  product 
or  technology  which  may  also  result  in  a  MNS  and/or  a  request  for  PE  65808  funding  for  studies  and 
analyses.  Finally,  any  of  the  product  center  XR  organizations  as  a  part  of  their  developmental  planning 
may  xlentify  a  n^  or  technological  opportunity  which  could  generate  a  need  for  low  level  internal 
studies  and/or  a  request  for  PE  65808  funding  for  studies  and  analyses. 

Other  resources  can  include  the  Air  Force  Studies  and  Analyses  Agency  (AFSAA),  the  Deputy  Chief  of 
Staff,  Plans  and  Operations  (HQ  USAF/XO),  the  Assistant  Secretary  of  the  Air  Force  for  Acquisition 
(SAF/AQ),  wargamers  at  Service  schools.  Product  Cer^ers,  and  Air  Logistic  Centers. 
Participation/support  requested  from  these  outside  resources  may  involve  informal  requests  for 
information  or  formal  contracted  efforts  for  studies  and  analyses.  In  selecting  outside  resources,  the 
MAJCOM  will  use  their  knowledge  that  a  particular  agency/organization  specializes  in  or  has  experience 
with  a  particular  activity  making  that  agency/organization  a  candidate  for  discussion/support. 

In  order  to  accomplish  M AA  and  MNA  (development  planning),  furxfing  is  needed  to  support  the  required 
studies  and  analyses  (unless  the  effort  is  being  conducted  within  the  MAJCOM  with  existing  personnel 
aixJ  no  additional  funding  is  required).  Funding  for  the  development  planning  process  comes  from  two 
sources:  the  formal  development  planning  process  and  the  MAJCOM  appropriated  funds. 
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The  development  planning  program  process  is  an  annual  exercise  intended  to  provide  a  prioritized, 
multi-year,  program  for  aU  Air  Force  development  planning  activities.  AF/XOR  is  the  Program  Element 
Monitor  (PEM)  for  Program  Element  (PE)  65808F  and  is  responsible  for  the  development  planning 
process.  The  process  has  three  distinct  phases;  (1)  proposed  study  development,  (2)  prioritization,  and 
(3)  integration.  (See  IFC  Block  C9,  Preliminary  Phase  and  Program  Budget  Requests,  for  budget 
impacts/considerations.) 

Around  1  March  of  each  year,  AF/XOR  sends  a  message  to  the  Using  Commands  and  HQ  AFMC  calling 
for  study  topics  for  the  next  4  years.  The  proposed  topics  are  evaluated  and  prioritized  by  an  0-6  level 
steering  grotfo  chaired  by  AF/XOR  in  early  July  of  the  same  year.  The  outcome  of  this  process  is  multi¬ 
year  PE  6S808F  program  with  funding  levels  identified  by  project.  The  process  also  leads  to  a  4  year 
program  linked  to  the  biennial  Planning,  Programming,  Budgeting  System  (PPBS)  cycle.  This  annual 
process  provides  a  single  program  that  simultaneously  itKiudes  inputs  for  the  next  year's  execution 
program,  cunent  Fiscal  Year  (FY)  +  2  Budget  Estimate  Submission  (BES)  cycle,  and  current  FY  3 
Program  Objective  Memorandum  (POM)  cycle. 

AFMC/XR  'Program  Management  Plan  for  PE  6S808F  Development  Planning'  goes  into  a  lot  rTx>re 
detail  on  how  the  process  works,  who  is  involved,  and  when  events  are  scheduled  to  occur.  It  also 
outlines  the  format  used  to  propose  study  topics.  You  should  be  able  to  obtain  a  copy  of  the  'Program 
Management  Plan  for  PE  65808F  Oevelopntent  Planning'  from  your  local  XR  office. 

When  appropriate.  MAJCOM  funding  may  be  used  to  supplement  and  leverage  the  Air  Force 
Development  Planning  funds.  (Development  Planning  funding  is  limited,  approximately  $10  million  in 
FY94.)  Typical  MAXOM  funding  sources  include  SPOs,  labs.  Using  Commands.  NASA,  ARPA,  and 
acquisition  support  funds. 

SAG  SuDr»rt 

Finally,  the  MAJCOM  needs  to  assess  the  need  for  a  senior  advisory  group  called  the  Study  Advisory 
Group  (SAG).  The  purpose  of  the  SAG  is  to  provide  oversight  and  direction  to  ensure  that  the  Operating 
and  Implementing  Commands  and  the  decision  makers  operate  in  concert.  The  SAG  should  consist  of 
representatives  from  the  principal  organizations  of  the  Operating  Command  staff  and  representatives 
from  the  Implementing  and  Support  Commands.  SAF/AQ.  SAF/FM,  USAF/XOR,  AFSAA,  and  others  as 
required.  SAGs  can  be  formed  very  early  pre-MS  0  in  order  to  review  the  MAJCOM  roadmaps  and 
provide  advice  to  the  MAJCOM  Commander.  They  may  also  be  planned  to  support  activities  associated 
with  approved  Mission  Need  Statements  (MNSs).  The  SAG  is  responsible  to  review  the  COEA  effort  at 
the  folfowirtg  points  in  the  process; 

-  Completion  of  the  COEA  plan  prior  to  the  Phase  0  analysis. 

-  Completion  of  the  phase  0  COEA  analysis  prior  to  submitting  the  results  to  the  Milestone  I  Review. 

~  Completion  of  the  updated  COEA  plan  prior  to  the  Phase  I  analysis 

For  major  efforts,  the  SAG  will  probably  review  the  alternatives  selected  for  irx^lusion  in  the  analysis.  For 
projects  requiring  a  significant,  long-term  analytical  effort,  the  SAG  will  probably  corKluct  a  review  at 
about  the  niidpoint  of  the  analysis.  At  some  point  after  a  favorable  Milestone  0  decision,  a  Concept 
Action  Group  (CAG)  is  formed..  The  CAG  will  then  be  guided  by  the  SAG  or  assume  the  re^xjnsibilities 
of  the  SAG  (in  which  case  the  SAG  would  be  abolished).  In  the  event  the  SAG  is  discontinued, 
members  of  the  SAG  may  and  should  be  selected  as  members  of  the  CAG  in  order  to  maintain 
continuity. 
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8.  ENTRANC&EXIT  CRITERIA: 

Entrance:  Activities  associated  with  mission  area  planning  are  cyclical  activities.  Requirements  are 
evaluated  annually  as  a  part  of  the  Air  Force  Planning  Guidance.  In  addition,  PE  65808  data  calls  occur 
annuaHy  and  the  POM  process  occurs  every  2  years. 

Exit:  These  activities  idemity  the  resources  (people  and  funding)  that  will  evaluate  the  force 
structure,  and  threat/study  groundiules  and  assumptions  in  support  of  MAA.  Industry  involvement  in 
MAA  and  MNA  is  also  initiated  by  the  action  officers  assigned  under  this  activity. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  Defense  Planning  Guide  (Review  National  Defense  Planning,  At). 

(2)  Air  Force  Regional  Plans  (Review  Air  Force  Planning  Guidance,  B1). 

(3)  MADPS. 

(4)  TIRRs. 

b.  Outputs: 

(1 )  Agreements  with  an  Air  Force  Agency  and/or  Industry  to  support  mission  area 
assessment  and  mission  need  analyses. 

(2)  SAG  Charter. 

10.  KEY  REFERENCES: 

a.  AFMCP  173-1,  AFMC  Cost  &  Operational  Effectiveness  Analysis  (COEA)  Handbook  ,  30  Dec  92, 
Chapter  3  (especially  para.  3.2),  which  describes  the  formation  and  functions  of  the  SAG. 

b.  AF1 10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and  Procedures,  16  Feb  93, 
Para.  1.1.2,  which  defines  the  Air  Force  role  in  the  national  planning  process. 

c.  “Requirements  Planning,"  Lt  Gen  Thomas  R.  Ferguson,  Jr.,  USAF,  and  Terrence  J.  Hertz,  M 
Universitv  Journal.  Summer  *90,  which  addresses  the  requirements  and  acquisition  processes. 

d.  Guide  to  the  Technology  Master  Process,  30  Oct  92,  prepared  for  AFMC/DPUL  by  TASC  of 
Fairborn,  Ohio,  which  covers  the  background,  description,  objective,  and  implementation  of  the  TPIPT 
process. 

e.  AFPD  1 0-6,  Mission  Needs  and  Operational  Requirements.  1 9  Jan  93,  Para.  1 . 1  -1 .6,  which 
defines  the  MNS  and  COEA. 

11.  IMPLEMENTATION  TOOLS:  None  identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  process  is  a  cyclic  process  which  begins  each  year  with  the  release  of  the  Air 
Force  Plans  and/or  via  the  TPIPT  process.. 
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b.  CONSTRAINTS: 

(1 )  Support  from  resources  (internal  and  external  to  the  MAJCOM)  will  be  constrained  by  the 
availability  of  funding  and  manpower  available  to  support  the  effort. 

(2)  The  past  few  years  congressional  staffers  have  approved  PE  65808F  plans  on  a  line-for-line 
basis.  If  an  item  or  study  is  scratched  by  these  staffers,  ‘he  associated  funding  is  also  eliminated  from 
PE  65808F. 

c.  RESOURCES:  Several  TPIPT  action  officers  will  need  to  be  identified  within  tne  MAJCOM  to 
support  all  activities  associated  with  this  data  ele.itent.  At  least  one  individual  from  the  implementing 
command  will  need  to  be  a  member  of  the  SAG  to  ensure  concerns  of  the  implementing  command  are 
addressed.  This  person  will  need  to  keep  functional  specialists  apprised  of  the  position  of  the  SAG  so 
that  acquisition  activities  can  be  accomplished  in  accordance  with  the  SAG  guidance.  Funding, 
manpower,  facilities,  and  equipment  requirements  will  vary  each  year  based  upon  the  magnitude  of  the 
mission  area  planning  task. 

d.  LESSONS  LEARNED:  While  the  SAG  is  formed  to  direct  the  studies  and  analyses  activities, 
caution  should  be  exercised  in  the  execution  of  their  direction.  The  MAJCOM  Commander  has  final 
approval  and  the  SAG  is  basically  an  advisory  body. 

e.  BEST  PRACTICES: 

(1 )  To  maintain  continuity,  members  of  the  SAG  should  be  reassigned  to  the  CAG  whenever 
possible  if  the  SAG  is  dissolved 

(2)  It  is  beneficial  to  have  the  SAG  review  the  MAJCOM  roadmap  before  the  TPIPT  applies 
resources  toward  specific  technologies. 

(3)  For  projects  requiring  a  significant,  long-term  analytical  effort,  the  SAG  should  conduct  a 
review  at  about  the  midpoint  of  the  analysis.  A  review  of  the  alternatives  selected  for  the  analysis  may 
also  be  irrcluded  for  major  efforts.  Reviews  should  also  be  conducted  to  resolve  issues  that  are 
hampering  the  study  effort. 

(4)  Get  the  intelligence  community  involved  early.  Consider  having  the  Defense  Intelligence 
Agency  (DIA),  HQ  USAF/IN,  and  AFIC  participate  in  planning  the  analysis. 

(5)  Constraints  and  assumptions  are  factors  that  limit  the  set  of  viable  alternatives  to  be 
considered.  They  should  be  carefully  defined  and  stated  explicitly.  Progress  sometimes  comes  from 
finding  that  a  presumed  constraint,  such  as  personnel,  funding  technology,  or  supportability  does  not 
actually  exist  or  can  be  easily  accommodated  with  simple  actions. 

f.  TRAPS: 

(1 )  A  lack  of  Implementing  Command  representation  on  the  SAG  could  result  in  decisions  on 
the  part  of  the  MAJCOM  which  are  not  affordable  or  executable  within  the  acquisition  process. 

(2)  While  in  theory  the  requirements  pull  approach  is  a  good  approach,  many  times  in  reality  the 
intent  of  the  approach  is  not  followed.  Instead  of  evaluating  potential  alternatives,  there  is  a  tendency  to 
concentrate  on  a  predetemiined  solution. 

(3)  Conflict  exists  between  the  requirements  process  and  the  budget  process.  The  PPBS  and 
annual  congressional  approval  activities  corrupt  the  entire  concept  of  incremental  milestone  planning 
because  they  require  the  military  to  budget  for  a  "program"  at  or  before  Milestone  0.  You  need  a  wedge 
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tor  post'MS  I  activities  into  the  POM  as  early  as  possible.  However,  the  'program’  is  not  approved  until 
MSI. 

(4)  MAJCOMs  and  other  agencies  using  industry  cost  data  should  take  care  to  ensure  that  total 
program  costs  are  reflected,  since  most  industry  cost  estimates  do  not  consider  many  Goverrunent  costs 
such  as  integration,  test,  data,  etc. 
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1.  ELEMENT:  C5.  TBS  0.1.6.0(IFC  93-3) 

2.  ELEMENT  TITLE:  Identify  Study  Ir^mts 

3.  ELEMENT  OWNER(S):  Operating  Commands 
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4.  ELEIIKNT  STAKEHOLDER(S):  Supporting  and  Implementing  Commands,  Product  and  Logistics 
Centers,  inteligence  Community.  Latxxatories,  and  Industry. 

5.  REQUIREMENT:  DOO  5000.1  (Part  1 ,  para  B2;  Part  2.  paras  Bland  B2,  paras  D3a  and  03b).  DOD  * 

5000.2  (Part  4.  Section  B.  para  3a).  AP1 10-601  (para  1.1.4)  and  AFPD  10-6  (para  1.2-1.3). 

6.  PURPOSeOBJECnVES: 

a.  Purpose;  The  purpose  of  this  activity  is  to  provide  a  common  MAJCOM  defined  framework 

for  the  Mission  Need  Analysis  (MNA).  • 

b.  Objectives;  The  objectives  are  to  provide  a  basis  for; 

(1 )  Realistic  operational  constraints  (bourxfaries)  for  use  in  the  MNA. 

(2)  Agreement  and  understanding  among  all  parties  including  other  DOD  and  Air  Force  • 

agencies  as  well  as  industry. 

(3)  Facilitating  an  apples-to-apples  comparison  of  alternatives  to  identify  Operating  Command 
needs  and  potential  concept  solutions. 

7.  DESCRIPTION:  To  accomplish  the  above  purpose  and  objectives  a  number  of  steps  need  to  be  ^ 

taken; 


a.  Obtain  Force  Structure  data  from  MAJCOM  local  point  in  XP.  DO  or  XR  . 

b.  Obtain  operational  concepts/constraints  from  MAJCOM  action  officers. 

c.  Define  a  threat  package  by  requesting  support  from  the  Air  Force  Intelligence  Community,  the  * 

National  Air  Intelligence  Center  (NAIC)  and  the  Operating  Command  Intelligence  office  for  the  timeframe 

of  irrterest.  (The  Product  Center  Director  of  Intelligence  (Dl)  is  the  focal  point  for  obtaining  Intelligence 
community  support  (ASC/NAIC/TIA  for  ASC.) 

d.  Develop  groundrules  and  assumptions  via  the  participation  of  all  key  players,  that  is.  the 

MAJCOM.  Supporting  Commands  and  agencies,  and  the  analysts  conducting  the  studies.  Iterate  the  R 

groundrules  and  assumptions  with  the  analysts  to  ensure  that  a  tractable  analyses  capability  exists  and 
that  an  affordable  and  timely  analyses  can  be  conducted. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Since  Force  Structure  definition  is  a  cyclical  activity  within  the  MAJCOM  planning  • 

organizations,  this  activity  can  start  at  any  time. 

b.  Conpletion  or  termination  of  this  activity  can  occur  upon  starting  the  MNA,  after  the  MNA  is 
underway,  or  if  the  Operating  Command  or  Air  Force  decides  against  conducting  an  MNA. 
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9.  KEY  INPUTS  AND  OUTPUTS:  There  are  a  number  of  inputsAxitputs  to  this  activity  and  they 
indude: 


a.  Inputs: 

(1 )  Defense  Planr^  Guidance  (Cl )  -  defines  framewortc  or  context. 

(2)  Operating  Command  Mission  Area  Plans  (C4)  -  spectfi^  force  dructure. 

(3)  Concept  of  Operations  (C2)  •  describes  use  of  force  structure. 

(4)  Intelligence  Documents  (B2)  -  describes  threat  to  the  force. 

(5)  Constraints  (groundrules,  assumptions,  and  conditions)  that  are  requisites  for 
njnning  Campaign,  M^ion,  Engineering  Supportability  Analysis  computer  models  (D4)  -  identifies 
tractable,  affordable  and  timely  analysis  capability 

b.  Outputs: 

(1)  Decision  on  scope  of  analysis  to  condud  the  Mission  Needs  Analysis  (C3). 

(2)  A  data  package  containing  all  of  the  necessary  detailed  information  for  corxluding 
the  Mission  Needs  Analysis,  which  includes  mnning  the  aforementioned  computer  models  (C3). 

10.  KEY  REFERENCES: 

a.  DOD  5000.1  (Part  1 ,  para  B2;  Part  2,  paras  B1  and  B2,  paras  D3a  and  D3b),  evolutionary 
requirements  definition,  requirements  generation  system.  Defense  Planning  Guidance. 

b.  DOD  5000.2  (Part  4  Sedion  B,  para  3a),  evolutionary  requirements  definition  procedures. 

c.  AF1 10-601  (para  1 .1 .4)  -  variety  of  analytical  methods  used  in  this  Task  to  neerf  process 
called  a  Mission  Need  Analysis  (MNA). 

d.  AFPD 1 0-6  (paras  1 .2  and  1 .3),  mission  deficiencies  will  be  identified  via  mission/capability 
assessment. 

11.  IMPLEIMENTAHON  TOOLS:  Threat  Environment  Description  (TED),  Defense  Planning  Guidance, 
Operating  Command  Roacfinaps,  and  TPIPT  Mission  Area  Developrinent  Plans. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Dedicated  30-  to  60-day  effort.  Program  Development  (ASC/YX)  involvement 
consists  primarfiy  of  reviewing  the  MNA  results.  Based  on  the  ASC/XR-ASC/YX  Memorandum  of 
Agreement  (MOA)  another  criteria  for  Program  Development  invdvement  would  be  an  Operating 
Command  dedsion  to  initiate  a  program  quickly.  This  adivity  would  be  completed  upon  coordination  of 
a  data  package,  the  document  containing  the  force  strudure,  groundmles  and  assunipiions,  by  the 
element  owners  and  stakeholders. 

b.  CONSTRAINTS:  A  number  of  potential  constraints  exist  and  they  include: 

(1)  lack  of  access  to  pertinent  classified  infonnation 

(2)  timely  availability  of  documents 

(3)  intelligence  documents  that  do  not  cover  the  timeframe  of  the  analysis 
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(4)  lack  of  identified/dedicated  focal  points  and  availability  of  perscfinel  with  right  skiHs 

c.  RESOURCES:  Primary  personnel  resources  will  consist  of  participants  from  the  Operating 
Command.  IntelBgence  community,  Product  Center  XR  analyst  and  TPIPT  members.  Minor  ASC/YX 
participation  may  be  accomplished  via  TPIPT  membersh^.  Travel  funds  arxj  secure  f»;ilities  may  also 
be  needed. 

d.  LESSONS  LEARNED:  This  must  be  a  team  effort  arxf  all  players  (Operating  Commarxf, 
Product  CerSers,  Intel  Community,  and  analyst)  must  buy-in.  If  agreement  and  buyin  is  not  achieved  up 
front,  the  effort  will  be  challenged  and  may  have  to  be  reaccomplished.  Establish  a  "grassroots*  Working 
Group  earty  on. 

e.  BEST  PRACTICES:  TalktotheASC/XRE  Multirole  Forces  Prefect  (MRFP)  team  about  their 
activities  during  1991  - 1992.  Work  with  OSD  PA&E  to  get  early  buy-in  on  the  approach,  ground  rules 
and  assumptions.  A  data  package  containing  all  of  the  necessary  detailed  information  for  cortducting  the 
Mission  Needs  Analysis  (MNA)  should  be  written  for  coordirration  by  all  of  the  key  players.  Since  this 
package  provides  the  basis  for  assessing  capabilities  of  current  systems  during  the  MNA.  it  could 
appropriately  be  called  a  "Capabilities  Assessment  Package’  (CAP). 

f.  TRAPS:  If  the  grourufrules  and  assumptions  are  not  consistent  with  the  Defense  Planning 
Guidance  (DPG),  OSD  PA&E  will  not  support  the  findings.  Furthennore,  the  follow-on  analyses  will  be 
questioned  unless  inclusion  of  the  appropriate  special  access  technologies  have  been  assumed. 
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1.  ELEMENT:  C6.  TBS  0.1. 7.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Conduct  Deficiency  Analyses 

3.  ELEMENT  OWNEfl(S):  Operating  Commands 

4.  ELEMENT  STAKEHOLOER(S):  Office  of  Secretary  of  Defense,  Joint  Chiefs  of  Staff.  Secretary  of 
Air  Force,  Air  Force  Materiel  Cominand  (AFMC).  Product  Center  XRs,  Aerorautical  Systems  Center 
(ASC),  ASCA'X,  Industry,  and  Laboratories. 

5.  REQUIREMENT: 

a.  Air  Force  Policy  Directlye  10-6, 1 9  Jan  93;  Air  Force  Instruction  (AFI)  10-601 .  Mission  Needs 
and  Operational  Requirements  Guidance  and  Procedures,  16  Jan  93,  Pages  2-4. 

b.  DoDI  5000.2,  Defense  Acquisition  Directive,  Part  4,  Section  B. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Deficiency  analyses  are  corxlucted  on  a  continuing  basis,  in  response  to  changing 
Air  Force  Planning  Guidance,  AFPG  (Service  peculiar  planning  document  developed  in  element  B1  in 
response  to  the  Defense  Planning  Guidance.  DPG)  and  Mission  Area  Assessments.  MAA  (Cl),  to 
evaluate  Air  Force  ability  to  accomplish  those  tasks  and  missions  using  current  and  programrned  forces. 

b.  Objectives:  Deficiency  analyses  involves  conducting  campaign  level  analyses  of  the  defined 
forces,  evaluating  their  ability  to  accomplish  theater  objectives  and  identifying  any  deficiencies  that  are 
found.  This  activity  is  typically  accomplished  with  the  support  of  Product  Center  XRs  (D4). 

7.  DESCRIPTION: 

a.  The  Deficiency  Analysis  represents  the  first  set  of  activities  in  a  process  known  as  the  Mission 
Needs  Analysis  (MNA).  The  fo^s  of  the  MNA  is  on  assessing  the  capabilities  of  current  and 
programmed  forces  to  corxiuct  operations,  achieve  the  goals  (missions  and  tasks),  arxj  consequently 
overcome  the  identified  threat  (B2)  (established  in  the  regional  scenarios  defined  in  the  MAA,  Cl)  and 
identify  operational  shortfalls  and  needs.  The  Deficiency  Analysis  employs  a  task-to-need  evaluation 
process  to  identify  operational  shortfalls  (deficiencies)  in  the  cuaent  and  programmed  forces  and  force 
structures.  Campaign  analyses  are  the  principal  tool  used  to  accomplish  these  task-to-need 
assessments.  If  the  results  of  the  campaign  analyses  show  that  the  forces  are  adequate  to  accomplish 
the  goals,  no  deficiencies  are  identified  and  the  activity  is  suspended  until  revised  tasks  and  missions  are 
generated  in  the  MAA.  If  deficiencies  are  identified,  then  follow-on  campaign  analyses  are  conducted  to 
assess  nonmateriel  solutions  or  combinations  of  nonmateriel  and  materiel  solutions  to  resolve  the 
deficiencies. 

b.  The  Operational  Command  is  responsible  for  ensuring  that  Deficiency  Analyses  are 
conducted  on  a  recurring  basis  in  response  to  updates  to  Cl .  C2,  and  C4.  The  Operational  Command 
has  the  freedom  to  contract  for  Deficiency  Analyses  (campaign  analyses)  support;  The  Product  Center 
XRs  are  typically  the  suppliers  of  choice  for  conducting  these  analyses  (D4). 

c.  Operational  shortfalls  (deficiencies)  are  identified  through  (computer)  simulations  of  conflicts 
irtvolving  US,  allied  and  enemy  forces.  Force  structures,  concepts  of  operations,  geography, 
environment,  target(s),  force  locations  and  force  element  capabilities  must  be  identified  for  both  sides  in 
the  conflict  in  order  to  conduct  the  campaign  analyses.  Warning  time,  deployment  decision  time  and 
start  of  conflict  information  are  critical  parameters  that  are  defined  for  all  forces  in  place  arKf  those 
available  for  deployment  from  (Xher  Services  and  allied  countries.  Performance  (our  ability  to  achieve 
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kterttified  tasks  and  accomplish  required  missions)  is  predicated  on  an  evaluation  oi  the  simulation 
results  against  predetermined  Measures  ot  Merit  (MOMs).  Failure  to  meet  operational  objectives 
(missions/tasks)  is  an  indication  of  potential  defidertcies  (operational  shortfalls).  Operational  shortfalls 
are  evaluated  using  continuing  campaign  level  analyses  to  determine  whether  a  materiel  need  exists  or 
whether  nonmateriel  alternatives  are  available  (change  in  doctrine,  operatbnal  concept,  tactics, 
organization  or  trdning).  This  analysis  is  documented  in  the  Operational  Shortfalls  (Deficiencies)  Report. 

8.  ENTRANCE/EXIT  CRITERIA:  This  activity  begins  when  the  strategy-to-task  framework  is 
established  and  total  force  projections  and  concepts  or  operations  are  identified.  It  is  complete  when  K 
has  been  determined  that  deficiervies  do  or  do  not  exist  and  a  report  containing  this  information  is 
approved. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs; 

(1)  Mission  definition  (tasks)  and  force  projections  (Cl). 

(2)  Concept  of  Operations  (C2 ). 

(3)  Threat  information  (B2). 

b.  Outputs:  The  results  of  campaign  analyses  are  documented  in  the  Operational  Shortfalls 
(Deficiencies)  Report  and  provided  to  the  MAJCOM  (C4  and  C7).  Outputs  include: 

(1)  Description  of  scenarios. 

(2)  Assumptions  and  constraints. 

(3)  Potential  Deficiencies. 

10.  KEY  REFERENCES:  Air  Force  Instoiction  10-601 .  Mission  Needs  and  Operational  Requirements 
Guidance  and  Procedures.  16  Feb  93. 

11 .  IMPLEMENTATION  TOOLS:  Deficiency  analyses  are  performed  using  models  (computer  based 
simulations)  that  describe  the  interaction  of  forces  af  the  campaign  level  and  assess  performance  in 
terms  of  predetermined  measures  of  merit.  The  results  indicate  potential  deficiencies,  not  solutions. 

12.  PLANNING  GUIDANCE:  Prior  to  campaign  analyses  to  identify  deficiencies,  the  analysts  must  be 
familiar  with  the  concept  of  operations  and  defined  missions  (tasks).  Scenarios  for  the  sinxjlated  conflict 
are  constructed  (identified)  based  on  this  input  information  (constraints  and  assumptions  must  be  clearly 
defined)  and  analytical  tools  are  tailored  to  account  for  specific  operational  concepts,  force  structures 
and  defined  scenarios.  The  strategic  information  documented  in  the  DPG/AFPG  and  the  tasks  identified 
in  the  specific  mission  area  must  be  made  available  to  the  performing  activity  to  ensure  that  a  thorough 
evaluation  is  conducted  and  proper  constraints  and  assum^ions  are  applied. 

a.  DURATION:  It  typically  takes  a  minimum  of  6  months  to  conduct  a  campaign  level 
deficiency  analyses.  For  complex  study  efforts  (missions  and  tasks  involving  the  interaction  of  muttipie 
systems  and  force  structures),  the  deficiency  analyses  may  take  a  year  or  more. 

b.  CONSTRAINTS:  It  is  the  responsibility  of  the  Operating  Command  to  ensure  that  the 
scenarios  conform  to  the  DPG  and  that  alt  assumptions  regarding  the  threat  and  US  and  allied 
involvemeni  (mix)  are  identified  and  appropriate.  Ail  relevant  situations  in  the  DPG/AFPG  scenarios 
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should  be  addressed  in  the  analysis.  US  force  availability  should  be  cor^sters  with  any  deployment  or 
reinforcement  objectives  included  in  the  scenarios  and  established  in  the  OPG/AFPG. 

c.  RESOURCES:  Resource  allocation  is  left  as  an  issue  for  the  specific  acquisition  activity 
Typically,  the  team  assigned  to  conduct  a  campaign  level  deficiency  analysis  would  include  functions 
covering  mission  analysis,  design  engineering  (including  software),  logistics  (supportabiMy),  cost, 
contracting  and  management. 

d.  LESSONS  LEARNED:  The  Air  Force  Lessons  Learned  Program  should  be  consulted  for 
current  lessons  learned  regarding  campaign  level  deficiency  analyses. 

e.  BEST  PRACTICES:  It  is  essential  that  the  Operating  Command  participate  in  the  deficiency 
analyses  (cortducted  by  a  supporting  organization,  such  as  ASC/XR)  at  a  level  sufficient  to  vorify  the 
assumptions  and  constraints  applied  by  the  analysts.  The  Operating  Command  must  also  participate  in 
identifying  measures  of  merit  for  determining  the  nature  of  deficiencies  and  verify  that  the  concepts  of 
operations  are  realistic  and  that  deficiencies  are  described  adequately  to  support  foilow-on  evaluation  of 
nonmateriel  solutions  (C7  and  07). 

f.  TRAPS:  The  results  of  any  campaign  simulation  are  very  dependent  upon  assumptions 
regarding  the  way  the  forces  are  allocated  in  accordance  with  the  initial  strategy  and  the  response  to  the 
situation  as  it  ev^es.  Alt  assumptions  made  in  support  of  performing  the  campaign  level  deficiency 
analysis  must  be  clearly  identified  arfo  sensitivity  analysis  of  their  impact  on  the  results  must  be 
conducted. 
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1.  ELEMENT:  C7.  TBS  0.1. 7.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Assess  Nonmateriel  Akematives 

3.  ELEMENT  OWNER(S):  Operating  command 

4.  ELEMENT  STAKEHOLDER(S):  Air  Staff,  MAXOMs,  FOAs,  AFMC,  and  wargamers  at  Service 
scfwols. 

5.  REQUIREMENT:  DODO  5000.1 .  Defense  Acquisition  Management  Documentation  arxf  Reports,  Feb 
91 ,  Part  2B2.  TNs  directive  contains  the  requirements  generation  of  the  mission  needs. 

6.  PURPOSE'CBJECnVES: 

a.  Purpose:  To  assess  whether  an  operational  shortfall  can  be  corrected  with  a  nonmateriel 
solution. 

b.  Objective:  Identify  nonmateriel  alternatives. 

7.  DESCRIPTION:  The  assessment  of  nonmateriel  alternatives  is  accomplished  as  part  of  the  Mission 
Need  Analysis  (MNA)  (C3).  If  a  MAJCOM  identifies  a  shortfall  in  its  ability  to  accomplish  a  task  or 
mission,  their  first  obligation  is  to  determine  if  a  change  in  tactics,  doctrine,  organization,  operational 
concepts,  support  concepts,  or  training  (nonmateriel  solutions)  may  solve  the  deficiency.  If  a 
nonmateriel  s^ution  cannot  be  found,  then  a  materiel  solution  (new  hardware  or  software)  is  required, 
which  initiates  the  development  of  the  preliminary  mission  need  statement  (MNS)  (Cl  2).  If  a 
rronmateriel  solution  is  found,  it  is  then  integrated  into  the  concept  of  operations  (CONOPS)  (C2).  At  the 
request  of  the  Operating  Command,  the  Product  Centers  can  letid  assistance  by  determining  the 

#  deficiency,  thereby  establishing  the  baseline  against  which  materiel  and  nonmateriel  solutions  can  be 
assessed  (D7). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  Completion  of  the  tasks  identified  during  the  MAA,  the  deficiency  analyses  (C6), 
and  identification  of  an  operational  shortfall. 

b.  Exit:  Determination  of  whether  a  nonmateriei  altemative  can  be  identified. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  Mission  area  assessment  (MAA)  (Cl),  completed. 

(2)  Results  of  deficiency  analysis  (C6). 

(3)  Investigation  results  of  Product  Center  support  of  nonmateriel  alternatives  (D7). 

b.  Outputs: 

(1)  Request  Product  Center  support  for  nonmateriel  altemative  assessment  (D7). 

(2)  Develop  the  preliminary  MNS  (C12),  if  a  materiel  need  is  identified. 

(3)  Return  to  CONOPS  development  (C2),  for  a  nonmateriel  altemative. 
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10.  KEY  REFERENCES: 

a.  AF1 10-601 ,  Mission  Neods  and  Operational  Requirements  Guidance  and  Procedures,  16  Feb 
33.  paragraphs  1.1.4, 1.1.6.  This  regulation  defines  the  planning  process  and  philosophy  for  the  MNA 
and  the  evolutionary  requirements  definition. 

b.  AFPD  10-6,  Mission  Needs  and  Operational  Requirements,  19  Jan  93,  paragraph  1 .3.  This  is 
the  directive  to  assess  all  nonmateriel  alternatives. 

c.  DOD  Directive  5000.1 ,  Defense  Acquisition,  23  Feb  91 ,  Part  1 ,  paragraph  B.2.a.,  directs 
examining  nonmateriel  solutions  as  part  of  evolutionary  requirements  definition. 

d.  DOD  Instoiction  5000.2,  Change  1 ,  Defense  Acquisition  Management  Policies  and 
Procedures,  26  Feb  93,  Part  3,  paragraph  2.a.(2),  directs  examining  nonmateriel  solutions  as  part  of  the 
determination  of  mission  needs. 

11.  IMPLEMENTATION  TOOLS;  None  Identified 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Varies  from  a  few  days  to  months  depending  on  magnitude  of  deficiency. 

b.  CONSTRAINTS:  None  Identified. 

c.  RESOURCES:  From  one  to  several  personnel  including  analysts,  logisticians,  and 
engineers.  Various  campaign  and  mission/effectiveness  models  for  analysis. 

d.  LESSONS  LEARNED:  Don1  attempt  to  proceed  to  Milestone  0  without  fully  exploring  this 
topic  or  OASD  will  send  you  back  to  complete  the  work  which  should  have  been  done  in  the  first  place. 

e.  BEST  PRACTICES:  None  Identified 

f.  TRAPS: 

(1 )  There  appears  to  be  a  lack  of  communications  between  the  user's  Requirements  and 
Operations  groups.  Some  Operations  people  claim  their  first  involvement  at  COEA,  others  claim  they're 
not  involved  until  after  developmental  testing. 

(2)  The  quality  of  the  assessmerrt  is  dependent  upon  the  completeness  of  the  deficiency 
analysis.  If  the  deficiency  analysis  is  by-passed  or  incornpiete,  then  an  incorrect  conclusion  may  be 
drawn. 
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1.  ELEMENT:  C9.  TBS  0.1. 9.8.1  (IFC  93-3) 

2.  ELEMKNT  TITLE:  Submit  Preliminary  Budget  Requests 

3.  ELEMENT  OWr«R(S):  Using  Commands 

4.  ELEMENT  STAKEHOLDER(S):  AF/XOR.  SAF/AQ/FMB.  AFMC/XR,  and  HQ  AFMC/XT/FM 

5.  REQUIREMENT:  Dod  Directive  7045.14,  The  Planning,  Programming,  and  Budget  System 
(PPBS),  22  May  84. 

6.  PURPOSEyOBJECTIVES:  The  purpose  of  the  initial  Program  Objective  Memorandum  (POM)  is  to 
e«isure  that  projected  fcjnding  is  included  in  the  Biennia!  Planning,  Program,  and  Budgeting  System 
(BPPBS).  The  objective  is  to  ensure  adequate  project  funding. 

7.  DESCRIPTION:  At  this  projects  point,  the  Air  Force  must  project  the  furyling  needed  if  a  materiel 
solution  is  required  (C7).  For  POM  purposes  this  would  be  considered  a  new  start  or  initiatives. 
Initiatives  need  to  be  supported  and  offset  by  the  usirrg  Major  Commands  (MAJCOMs)  who  will  benefit 
from  their  development  arrd/or  production.  (An  offset  is  a  funds  reduction  in  a  program  that  is  made  in 
order  to  provide  funding  for  another  program  which  has  been  assigned  a  higher  priority  .)  Support  for 
initiatives  must  be  solicited  early  in  the  BPPBS  cycle  from  the  using  MAJCOMs  by  the  proposing  AFMC 
organizations  if  any  success  can  be  expected. 

The  using  MAJCOM  Point  of  Contact  (POC)  will  be  the  Studies  Advisory  Group  (SAG)  leader 
(reference  C4,  Form  Action  Officer  Working  Group).  The  ASC  project  manager  should  work  with  the 
SAG  to  determine  what  activities  should  occur  during  the  POM  years.  ASC  will  be  tasked  to  estimate 
how  much  these  activities  will  cost  (D77)  and  prejsare  a  POM  input. 

Air  Force  Materiel  Command  (AFMC)  provides  HQ  USAF  "for  information  only"  initiatives  on 
acquisition  programs  which  are  being  executed  for  the  using  MAJCOMs.  These  initiatives  contain 
program  and  pricing  information  for  use  by  the  Resource  Allocation  Teams  (RATs)  if  the  initiatives  are 
introduced  into  the  AF  POM  formulation  process  by  the  using  MAJCOM  or  HQ  USAF  sponsor. 

After  the  ASC  project  officer  prepares  the  cost  estimate  and  the  MAJCOM  POM/BES  is  ready  to  be 
submitted  to  Air  Staff  (B5),  they  must  first  be  reviewed  and  approved  by  the  using  MAJCOM.  If  a  SAG 
has  not  been  established,  it  is  recommended  that  a  review  and  buy-in  be  conducted  by  the  using 
MAJCOM  POC  POM  focal  point  and  comptroller  Cost  Analysis  function. 

The  PPBS  Primer.  7th  edition,  Jan  93,  Chapter  4.2.3,  provides  more  information  on  the  MAJCOM 
POM  development  process. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  need  for  the  effort  described  above  at  this  phase  of  the  project  should  be 
dejjendent  on  the  anticipated  ability  to  interject  the  estimated  project  costs  into  the  Air  Force  POM  to 
establish  a  preliminary  financial  position  of  the  anticipated  program.  It  is  important  to  establish  a  POM 
funding  line  as  soon  as  possible  after  it  is  determined  that  a  materiel  solution  is  required. 

b.  Exit:  Inclusion  of  a  wedge  into  the  Air  Force  POM. 
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9.  KEY  INPUTS  AND  OUTS: 

a.  Inputs; 

(1)  Prelinfiinary  cost  estimate  and  associated  groundrules  and  assumptions  (develop 
Preliminaty  Cost  Estimates  (D77)). 

(2)  Program  Decision  Package  (POP)  Support  Package  (D77). 

(3)  Mission  Need  Statement  (MNS);  May  not  be  complete.  You  just  have  an  idea  of 
what  requirement  exists  and  can  compare  it  to  other  similar  program  (MNS)  ( C1 2). 

b.  Outputs:  POM  submission  to  AF/XOR. 

10.  KEY  REFERENCES: 

a.  DODI  7047.7,  Implementation  of  the  Planning.  Programming,  and  Budgeting  System  (PPBS), 
23  May  84. 

b.  AFP  1 72-4,  The  Air  Force  Budget  Process.  Oct  87. 

c.  POM  Guidance,  issued  biannually  from  AF/PE,  usually  around  June  of  odd  numbered  years. 

d.  AFSC  Financial  Management  Handbook,  Chapter  1,  Nov  92,  provides  information  on  the 
Biennial  Programming,  Planning,  and  Budgeting  System  (BPPBS). 

11.  IMPLEMENTATION  TOOLS: 

The  PPBS  Primer,"  7th  Edition.  Jan  93.  This  document,  while  still  "draft,"  is  published  by  the 
Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and  provides  a  valuable 
description  of  the  current  PPBS  process.  This  is  one  of  the  few  documents  that  describes  the  current 
process,  in  detail.  Further,  it  defines  the  activity  schedule  for  the  development  of  the  POM. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Approximately  9  months.  Normally  the  POM  process  starts  in  the  spring  of  odd 
numbered  years  when  the  Air  Staff  provides  each  MAJCOM  with  a  current  repriced  AF  baseline  and  a 
MAJCOM-specific  baseline.  In  the  fall  of  the  odd  numbered  years,  the  MAJCOMs  present  their  POM 
proposals  to  HQ  USAF.  ASC  involvement  usually  starts  in  May  of  odd  years  and  continues  through  July. 

b.  CONSTRAINTS: 

(1)  The  primary  constraints  to  the  activity  are  the  resource  limitations  placed  on  the 
MAJCOM  by  the  Air  Force  and  OSD,  and  the  schedule  limitations  on  management  reviews  inherent  in 
the  budget  timetable. 

(2)  A  second  constraint  is  limited  data  (being  pre-Milestone  0)  from  which  to  submit  an 
input  that  could  cover  the  next  6  years.  Yet;  if  an  input  is  not  made,  there  may  be  adequate  funding  in 
the  future  if  a  project  does  proceed. 

(3)  The  supporting  cost  estimate  will  have  to  be  done  at  a  very  high  level  because  very 
little  is  known  about  how  the  program  will  be  structured.  Because  of  this,  the  estimate  should  only 
address  the  POM  years.  The  whole  purpose  of  an  estimate  and  a  POM  at  this  time  is  just  to  ensure 
funding  is  available  when  a  favorable  Milestone  0  decision  is  made. 
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(4)  The  using  MAJCOMs  will  have  to  prioritize  their  requirements.  As  the  budget 
becomes  tighter  during  this  draw  down  period,  hard  choices  will  have  to  be  made  if  new  starts  are  to 
receive  funding. 

c.  RESOURCES:  The  Product  Center  project  manager  needs  to  stay  in  constant  contact  with 
the  MAJCOM  POC  and  the  Program  Element  Monitor  (PEM).  The  PEM  is  the  overall  Air  Force  focal 
point  for  his  or  her  programs  and  must  interface  with  the  Resource  Allocation  Team  to  ensure  the 
Program  Element  (PE)  is  supported  properly.  A  few  weeks  of  project  manager  and  cost  analyst  time 
may  be  required  to  prepare  the  POM  input  and  answer  “what-ifs''  and  other  questions. 

d.  LESSONS  LEARNED: 

(1)  During  the  Air  Staff  POM  deliberations  and  reviews,  it  is  important  that  the  project 
managers  keep  in  close  contact  with  the  project  representative(s)  in  AF/XO  (and  SAF/AQ,  if  someone 
has  been  identified).  This  is  important  to  help  resolve  issues  that  may  arise,  and  to  ensure  that  they  fully 
understand  all  the  pertinent  aspects  of  the  project,  and  can  defend  the  projected  resource  requirements. 
Also,  development  of  the  POM  is  a  comprehensive  and  complex  task,  and  the  information  requested  can 
be  expected  to  change  with  every  submission.  Therefore,  the  POM  analyst  in  the  project  office  needs  to 
ensure  that  (s)  he  is  not  only  in  compliance  with  the  formal  tasking  and  the  local  budget  staff  instructions, 
but  also  satisfies  the  information  and  documentation  needs  of  the  Air  Staff  project  representative. 

(2)  May  want  to  create  the  budget  line  in  an  existing  program  especially  if  developing  a 
weapon  system  to  replace  one  that  already  exists  or  a  modification  for  an  existing  weapon  system. 

e.  BEST  PRACTICES: 

(1)  After  submission  of  the  POM  package,  the  project  office  should  posture  itself  to  be 
able  to  respond  effectively  to  programmatic  questions,  and  to  be  able  to  generate  quantitative  answers  to 
Air  Staff  requests  to  develop  and  price  out  program  variations  to  the  POM  submission.  The  capability  to 
generate  this  "what-ir  information  in  a  timely  (and  quality)  manner  is  important,  since  the  reconciliation 
and  rankings  to  be  performed  by  the  Resource  Allocation  Teams  may  require  modifications  to  the 
MAJCOM  POM  requests  and  programs  in  terms  of  funding  levels,  quantities,  schedules,  or  other 
programmatic  asp^s.  If  a  project  office  is  unable  to  provide  the  necessary  information,  or  not  in  time  to 
support  the  decision  makers,  the  project  may  not  be  supported  or  approved  with  sufficient  funding  levels. 

(2)  Get  SAF/AQ  involved  as  early  as  possible. 

f.  TRAPS: 

(1)  Lack  of  clear  explanation/documentation  that  this  budget  wedge  is  anything  more 
than  just  an  initial  budget  line  and  isn't  backed  up  by  an  estimate  of  a  real  program  (i.e.,  estimate  doesnl 
represent  a  full  estimate  of  the  anticipated  program).  Sometimes  these  estimates  can  become  engraved 
in  stone  even  before  an  official  approach  has  been  agreed  on  (i.e.,  new  aircraft  or  mod  existing  aircraft), 
that's  why  we  recommend  only  estimating  from  MS  0  decision  through  POM  years  (may  not  even  cover 
all  of  Phase  0). 


(2)  If  the  POM  is  the  first  for  the  project,  the  submission  will  be  considered  a  "New 
Start,"  and  identified  as  such.  There  may  be  additional  documentation  requirements  and  a  higher  level 
of  review  for  these  programs,  since  there  is  no  existing  funding  line.  Due  to  this,  the  project  office  must 
be  especially  prepared  to  defend  project  requirements. 
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1.  ELEMENT:  C11.  TBS  0.2.1. 2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Establish  IMPACTS  Planning  Team 

3.  ELEMENT  OWNER(S):  SAF/AQX 

4.  ELEMENT  STAKEHOLOER(S):  ASC/ALLH,  Operating  Command.  ASC/EN,  AFMC/XR.  and  Product 
Center  XRs. 

5.  REQUIREMENT :  DoDI  5000.2,  Defense  Ar^isition  Management  Policies  and  Procedures,  23  Feb 
91 ,  Part  7,  Section  B,  Human  Systems  Integration.  Describes  the  DoD  requirement  for  irKX)rporating 
Human  Systems  Integration  in  weapon  system  acquisitions. 

6.  PURPOSeOBJECnVES: 

a.  Purpose:  The  purpose  of  establishing  an  Integrated  Manpower,  Personnel  and 
Comprehensive  Training  and  Safety  (IMPACTS)  Planning  Team  is  to  bring  together  the  necessary 
expertise  required  to  assess  and  address  issues  within  individual  IMPACTS  elements,  such  as 
manpower,  personnel,  training,  and  safety  constraints,  and  to  provide  a  forum  for  assessing  trade-offs. 

Up  to  Milestone  0,  this  process  is  mearrt  to  be  very  approximate  and  non  time-consuming  because  of  the 
lack  of  specificity  associated  with  the  Mission  Need  Statement  (MNS)  process.  After  Milestone  0,  a  more 
in-depth  analysis  will  be  required. 

b.  Objectives:  To  improve  the  analysis  and  integration  of  IMPACTS  considerations  in  the  Air 
Force  systems  acquisition  process. 

7.  DESCRIPTION: 

a.  DoDI  5000.2,  Part  7,  Section  B,  requires  that  human  considerations  be  integrated  into  the 
design  of  defense  systems  in  order  to  focus  on  the  capabilities  and  limitations  of  the  airman  in  order  to 
improve  total  system  performance  and  reduce  costs  of  ownership.  The  Air  Force  initiative  to  incorporate 
Human  Systems  Int^ration  (HSI)  into  Air  Force  weapon  system  programs  is  called  IMPACTS.  The 
IMPACTS  program  is  a  comprehensive  management  and  technical  approach  for  addressing  the  human 
centered  elements  of  manpower,  personnel,  training,  safety,  health  hazards,  and  human  factors 
engineering  in  the  acquisition  of  new  or  improved  systems. 

b.  Pre-Milestone  0  goals,  constraints,  aixJ  objectives  are  developed  through  a  thorough  analysis 
of  the  predecessor  system  or  new  system  concepts.  These  goals,  constraints,  and  objectives,  along  with 
a  strategy  for  meeting  them,  are  documented  in  the  Preliminary  IMPACTS  Program  Plan  (P-IPP). 

c.  An  IMPACTS  Planning  Team  is  formed  at  the  end  of  the  Mission  Need  Analysis  (MNA) 
process  (if  a  materiel  solution  is  needed)  (C7)  arfo  in  time  to  provide  inputs  into  the  writing  of  the  Mission 
Need  Statement  (MNS)  (Cl  2).  It  is  chaired  by  the  Operating  Command  prior  to  Milestone  I.  After 
Milestorre  I  and  System  Program  Office  (SPO)  formation,  it  will  be  chaired  by  the  Implementing 
Command.  The  team  members  vary  based  on  the  project  but  should  include  representatives  from  the 
Operating,  Implementing,  and  Participating  Commands  and  other  supporting  agencies  who  are  tasked 
with  development  and  implementation  of  HSI  strategy  for  new  or  modified  systems  (D9). 

d.  The  primary  objective  of  the  planning  team  is  to  improve  the  analysis  and  integration  of 
IMPACTS  considerations  in  the  Air  Force  systems  acquisition  process.  The  planning  team  efforts  must 
reflect  the  concerns  and  planning  efforts  of  the  Operating  Command  and  the  Implementing  Command. 

To  attain  this  objective,  the  following  applies: 

(1)  Ensure  that  IMPACTS  considerations,  factors,  and  constraints  are  identified  and 
included  in  the  MNS  when  the  potential  to  provide  an  optimally  supported  system  is  greatest. 
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(2)  Integrate  IMPACTS  considerations  into  the  acquisition  process  along  with  cost, 
schedule,  performance,  reliability,  and  maintainability. 

(3)  Ensure  that  training  planning,  rec^irements  analysis,  and  training  equipment 
development  and  production  are  planned,  coordinated,  and  funded. 

(4)  Establish  and  use  data  sources,  analytical  tools,  and  procedures  that  support 
IMPACTS  element  trade-off  analyses  during  the  Milestone  Decision  process. 

(5)  Provide  IMPACTS  analysis  results  to  decision  authorities;  emphasize  life  cycle  cost 
and  the  effective  use  of  critical  manpower,  personnel,  and  training  resources. 

e.  Planning  and  coordinating  an  IMPACTS  program  require  an  initial  focus  on  the  predecessor 
system  to  establish  a  baseNne  and  to  develop  input  to  subsequent  studies  and  plans.  This  analytical 
process  is  used  to  identify  existing  manpower,  personnel,  training,  safety,  health  hazards,  and  human 
factors  engineering  *high-drivers.’  'High-drivers''  are  those  tasks  that  are  costly  in  terms  of  manpower, 
personnel,  or  training  resources.  Logistics  Support  Analysis  (LSA)  Task  203,  prior  to  Milestone  0, 
provides  a  method  of  addressing  these  issues  as  a  Baseline  Comparison  System  is  defined.  The 
IMPACTS  predecessor  analysis  process  is  focused  on  information  typically  available  at  Operatrig 
Command  headquarters  for  the  identification  of; 

(1 )  Predecessor  system(s)  lessons  learned  arxJ  the  development  of  a  predecessor 
"footprint'  or  baseline. 

(2)  Predecessor  'high  driver"  tasks. 

(3)  Initial  IMPACTS  element  considerations  (goals  and  constraints). 

(4)  Technological  opportunities  and  new  training  employment  scenario  possibilities. 

f.  IMPACTS  Planning  Team  responsibilities  include  initial  predecessor  analysis  and 
development  of  the  Preliminary  IMPACTS  Pr^ram  Plan  (P-IPP).  The  effectiveness  of  the  planning 
team  will  depend  on  how  rapidly  they  form,  initiate  appropriate  analysis,  and  provide  input  for  the 
acquisition  documentation. 

(1)  The  P-IPP  contains  a  summary  of  the  high-driver  considerations  from  the  IMPACTS 
Predecessor  Analyse  Process  and  senres  as  the  central  management  document  for  the  system-specific 
IMPACTS  program.  It  is  developed  in  six  parts  outlined  in  Appendix  B  of  the  IMPACTS  Process 
Handbook,  Apr  91 . 

(2)  The  P-IPP  is  used  by  the  Operating  Command  to  support  development  of  the 
Preliminary  MNS  (C12)  and  is  an  evolutionary  plan  that  supports  the  IMPACTS  process  throughout  the 
life  cycle  of  a  system.  Prior  to  Milestone  I,  it  is  updated,  coordinated  with  the  IMPACTS  Planning  Team 
members,  and  approved  by  the  operating  command's  Deputy  Chief  of  Staff  (DCS)  for  Requirements  (or 
equivalent). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrarx:e;  The  formal  IMPACTS  process  begins  with  the  identification  by  the  Operating 
Command  of  a  need  that  requires  a  materiel  (hardware/software)  solution. 

b.  Exit;  The  activity  is  an  iterative  process  and  continues  throughout  the  life  of  the  system. 
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9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs:  Mission  Need  Analysis  (MNA)  (C3) 

Assess  Non-nrtalefiei  Alternatives  (C7) 

b.  Outputs:  Prelin«nary  IMPACTS  Program  Plan  (P-IPP) 

Risk  Assessment  to  Integrated  Program  Summary 
IMPACTS  input  to  MNS  (C12) 

10.  KEY  REFERENCES: 

a.  AP1 10-601, 16  Feb  93,  Page  12,  Paragraph  1.14;  Attachment  4,  Section  B,  MNS  Format, 
Paragraph  5;  and  Attachment  6,  Section  B,  Operational  Requirements  Documerrt  (ORD)  Format, 
Paragraph  S.c.  States  the  requirement  to  include  manpower,  personnel  and  training  considerations  into 
the  MNS  and  ORD. 

b.  IMPACTS  Process  Handbook,  Apr  91 ,  HO  USAF/MOR,  provides  a  guide  for  the  initiation  arxf 
development  of  an  IMPACTS  program. 

c.  Air  Force  Acquisition  Model  (AFAM). 

d.  Automated  Lessons  Learned  Capture  and  Retrieval  System  (ALLCARS). 

e.  AFR  26-1 ,  Vol  V,  Integrated  Manpower,  Personnel  and  Comprehensive  Training  and  Safety 
(IMPACTS)  Program,  provides  policy  and  establishes  responsibilities  for  incorporating  IMPACTS  into 
systems  engineering  and  program  management  of  Air  Force  acquisitions  and  modifications. 

11.  IMPLEMENTATION  TOOLS: 

a.  Computer  Supported  Network  Analysis  System  (CSNAS)  has  models  for  IMPACTS  for  each 
of  the  acquisition  phases  and  can  be  obtained  from  ASC/ALL,  Wright-Patterson  AFB  OH,  DSN  785- 
5555. 

b.  LSA  provides  a  OoD  methodology  for  analyzing  manpower,  personnel  and  training. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  IMPACTS  Planning  Team  meetings  should  take  between  1  to  3  days  each. 
Initialty,  the  planning  team  should  meet  quarterly  and  then  as  required  throughout  the  life  of  the  program. 

b.  CONSTRAINTS: 

(1)  Funding  for  travel. 

(2)  Availability  of  appropriate  personnel  to  attend  the  meetings. 

(3)  Program  slips  due  to  program  funding  shortfalls. 

(4)  Nonavailability  of  predecessor  system  information/data. 

c.  RESOURCES:  The  IMPACTS  Planning  Team  is  formed  by  the  Operating  Command,  with 
assistance  from  the  Implementing  Command,  at  the  end  of  the  MNA  process  (if  a  materiel  solution  is 
needed)  and  consists  of  representatives  from  the  Implementing,  Operating,  ai^  Participating  Commands 
and  other  supporting  agencies  tasked  with  the  development  and  implementation  of  human  systems 
integration  strategy  for  new  Air  Force  weapon  acquisitions  or  modifications. 
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d.  LESSONS  LEARNED:  The  following  Lessons  Learned  were  extracted  from  the  Automated  <1^ 

Lessons  Learned  Capture  and  Retrieval  System  (ALLCARS)  maintained  by  ASC/CYM  at  Wright-  I 

Patterson  AFB  OH  45433-5000,  DSN  785-3454.  Additional  Lessons  Learned  can  be  found  in  AFAM, 

under  Section  1 .9.2.2,  Manage  the  M&P  Program.  ^ 

(1)  Without  good  frorrt-end  analysis  of  predecessor  systems,  ILS  and  supportability 
issues  will  surface  only  when  the  materiel  system  is  in  the  hands  of  the  user,  (reference  AF  Lessons 
Learned  #1643). 


(2)  Without  property  trained  people  in  the  right  place  at  the  right  time,  our  major  weapon 
systems  are  just  so  much  'metal  on  the  ramp*  (reference  AF  Lessons  Learned  #1726). 

e.  BEST  PRACTICES:  The  Deputy  Project  Manager  tor  Logistics  (DPML)  or  Integrated 
Logistics  Support  Manager  (ILSM)  for  IMPACTS  must  be  members  of  the  IMPACTS  Planning  Team. 
They  review  the  P-IPP/IPP  to  ensure  that  the  document  contains  appropriate  information  regarding 
IMPACTS.  Projects  which  do  not  comprehensively  plan  the  activities  related  to  IMPACTS  will  fail  to 
acquire  the  assets  needed  to  operate  or  support  the  project  throughout  its  life  cycle. 

f.  TRAPS:  Failure  to  have  the  proper  representation  from  the  appropriate,  experierK:ed  players 
may  result  in  poor  planning,  lack  of  supportability.  and  poorly  trained  personnel. 
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1.  ELEMENT:  C1 2.  TBS  0.2.1. 1  (IFC93-3) 

2.  ELEMENT  TITLE:  Develop  Preliminary  Mission  Need  Statement 

3.  ELENKNT  OWNER(S):  Operating  Command 

4.  ELEMENT  STAKEHOLOER(S):  Product  Centers.  CINCs.  and  HQ  USAF 

5.  REQUIREMENT:  DOD  Directive  5000.2,  Defense  Acquisition,  23  Feb  91.  Part  4.  Section  B.  This 
section  descrbes  the  evolution  of  mission  needs  and  requirement  to  prepare  a  MNS. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Identify  and  document  a  mission  deficiency  that  requires  a  materiel  solution. 

b.  Objectives:  Describe  the  deficiency  in  broad  operational  capability  terms  (nonsystem  specific). 
Identify  the  projected  threat  environment  and  applic^t^  operational  constraints. 

7.  DESCRIPTION: 

a.  DODI  5000.2  requires  a  Mission  Need  Statement  (MNS)  be  completed  at  Milestone  0.  A  MNS  is 
required  for  all  potential  materiel  acquisition  programs,  not  ^st  major  programs.  MNS  that  may  result  in 
a  major  new  defense  acquisition  program  (ACAT I)  must  be  sent  through  the  Air  Staff  (B7)  to  the  Joint 
Requirerrtents  Oversight  Council  (JROC)  (A6).  The  JROC  reviews  the  MNS  (A8),  validates  and 
approves  the  mission  need,  and  is  the  initial  Milestone  Review  link  with  the  requiremerifts  ger^ration 
system.  The  JROC  sends  the  MNS  to  the  DAB  for  the  Milestone  Review  (A9).  For  nonmajor  new 
defense  programs  (ACAT  ll-IV),  MNS  are  validated  by  the  Operating  Command,  sent  to  the  Air  Staff  for 
approval,  then  presented  to  the  AFSARC  for  the  Milestone  Review. 

b.  The  Operating  Command  continually  assesses  its  mission  and  identKies  operational  and  support 
system  deficiencies.  Mission  deficiencies  are  identified  as  a  direct  result  of  a  continuing  assessment  of 
current  and  projected  capabilities  in  the  context  of  changing  military  threats,  national  defense  policy  (A1 ) 
and  Air  Force  defense  p^icy  (B1 ).  A  mission  need  analysis  (C3)  that  results  in  a  deficiency  requiring  a 
materiel  solution  will  necessitate  a  MNS. 

c.  The  MNS  defines  projected  needs  in  broad  operational  terms.  The  MNS  must  contain  an 
assessment  of  why  non-materiel  solutions  were  determined  to  be  inadequate  (C7).  The  MNS  should  be 
brief,  succinct,  and  clearly  state  a  mission  deficiency  or  technological  opportunity.  The  Operating 
Command  will  define  the  need  in  terms  of  mission,  objective  and  general  capabilities,  not  in  terms  of 
equipment  or  system  specific  performance  characteristics.  The  following  factors  should  be  considered  in 
writing  the  MNS: 

(1 )  Must  make  a  determination  (often  highly  subjective)  of  whether  or  not  an  identified  need 
could  result  in  the  initiation  of  a  new  major  defense  acquisition  program.  Where  there  is  doubt,  the  need 
should  be  treated  as  if  it  would  result  in  a  major  defense  acquisition  program. 

(2)  Identify  needs  that  could  result  in  a  capability  that  may  require  the  use  of  new,  leading  edge 
technologies;  an  extensive  development  effort;  or  the  initiation  of  a  major  upgrade  to  an  existing  system 
that  has  significant  quantities  already  fielded. 

d.  The  MNS  wilt  also  identify  potential  materiel  alternatives.  The  project  team  (consisting  of 
Operating  Command  OPR  and  Product  Center  development  planners,  program  developers,  and  labs) 
will  support  development  of  those  alternatives  (D9)  but  will  not  evaluate  them  until  Phase  0  (D37).  If  an 
opportunity  exists  at  this  time  to  insert  a  funding  wedge  in  the  POM,  the  Operating  Command  will  submit 
a  budget  request  (C9)  to  the  Air  Staff  (B5)  and  eventually  to  OSD  (A4).  The  budget  request  would  be 
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supported  l>y  a  very  rough  cost  estimate  generated  by  the  project  office  (D77),  probably  based  on  the 
worst  case  alternative. 

e.  Initial  Integrated  Manpower,  Personnel  and  Comprehensive  Training  and  Safety  (IMPACTS) 
planning  will  begin  during  development  of  the  MNS  (Cl  1 ).  The  MNS  should  describe  any  constraints 
associated  with  initial  findings. 

f .  The  Air  Force  shall  consolidate  similar  deficiencies  of  multiple  MAJCOMs  and/or  other  Services. 
Integrated  needs  that  share  a  common  solution  can  contribute  to  lower  costs,  prevent  duplication  of 
effort  during  development,  and  result  in  improved  commonality,  standardization,  and  interoperability  of 
weapon  systems.  If  the  MNS  indicates  that  the  set  of  alternatives  may  include  other  programs  already  in 
development,  then  the  Operating  Command  must  contact  the  appropriate  Program  Executive  Officer  to 
ensure  applicable  program  management  directives  are  reviewed  and  revised,  if  required,  to  support 
concept  exploration  and  definition  studies. 

g.  The  MNS  consists  of  five  major  categories.  See  DOD  5000.2-M,  Part  2,  Attachment  1 ,  and  API 
10-601 ,  Attachment  4,  for  procedures  and  format. 

(1)  Defense  Planning  Guidance  Element  Idemify  the  major  program  planning  objectives  or 
section  of  the  Defense  Planning  Guidance  and  mission  areas. 

(2)  Mission  and  Threat  Analyses:  This  section  identifies  and  describes  the  mission  need  or 
deuciency.  This  section  should  include  a  discussion  of  the  Defense  Intelligence  Agency-validated  threat 
to  be  countered  as  well  as  the  projected  threat  environment  and  shortfalls  of  existing  capabilities. 

(3)  Nonmateriel  AHematives:  This  section  discusses  the  results  of  the  mission  area  analysis  and 
why  nonmateriel  alternatives  were  judged  to  be  inadequate. 

(4)  Potential  Materiel  Alternatives:  Identify  known  systems  or  programs  addressing  similar 
needs  that  are  deployed  or  in  development/production  by  any  of  the  Services  or  Allied  nations.  This 
section  should  cover  potential  inter-Service  or  Allied  cooperation  and  indicate  potential  areas  of  study  for 
concept  exploration/definition.  Operating  MAJCOM  must  be  cautioned  not  to  evaluate  the  alternatives. 

(5)  Constraints:  This  paragraph  describes,  where  applicable,  key  boundary  conditions  related  to 
infrastmcture  sup|3ort  that  may  impact  on  satisfying  the  need:  including  mission  planning  needs;  arms 
control  treaties;  logistics  support;  transportation;  mapping,  charting  and  geodesy  support;  manpower, 
personnel  and  training  constraints;  command,  control,  communications,  and  intelligence  interfaces; 
security;  arKf  standardization  or  interoperability  within  the  North  Atlantic  Treaty  Organization,  other  allies, 
or  Department  of  Defense  components.  This  will  include  the  level  of  desired  mission  capability  based  on 
operational  environment. 

(6)  Joint  Potential  Designator:  This  indicates  the  level  of  other  Service  interest  and 
participation. 

h  DODI  5000.2  states  that  there  should  be  a  single  MNS  format.  The  Air  Force,  however,  has 
defined  several  types  of  MNS  and  these  are  referenced  in  AF1 10-601 ,  paragraph  1 .3. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Identification  of  a  mission  deficiency  or  technology  opportunity  requiring  materiel 
solutions  based  on  mission  needs  analysis. 

b.  Exit:  Draft  MNS  ready  for  staffing  and  coordination. 
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9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Infxits:  ^ 

(1)  Defense  Planning  Guidance  (A1). 

(2)  Assessment  of  non-materiel  alternatives  (C7). 

(3)  Identification  of  a  deficiency  that  requires  a  materiel  solution  (C3).  ^ 

(4)  Potential  materiel  altematives  (09). 

(5)  Threat  information  (B6). 

(6)  Constraints  to  meeting  the  need,  including  results  of  IMPACTS  planning  (C1 1 ). 

b.  Output:  Draft  MNS  ready  for  staffing  and  coordination. 

10.  KEY  REFERENCES: 

a.  DOD  5000.2-M,  Defense  Acquisition  Management  Documentation  and  Reports.  Feb  91 ,  Part  2, 

Atch  1 .  • 

This  attachment  explains  the  format  requirements  for  developing  a  MNS. 

b.  DOD  Instnjction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  Feb  91 ,  Part 
3,  paragraph  2.  This  section  explains  how  the  MAJCOMs  determine  their  mission  needs  in  various 
acquisition  phases. 

c.  AF1 10-601 ,  Mission  Needs  arxf  Operational  Requirements  Guidance  and  Procedures,  16  Feb  93,  ^ 

paragraph  1 .3  and  Attachment  4.  Paragraph  1 .3  explains  the  different  types  of  MNS  and  Attachment  4 

provides  detail  procedures  and  format  in  developing  a  MNS. 

d.  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  Memorandum  of  Policy  (MOP)  No.  77, 

Requirements  Generation  System  Policies  and  Procedures,  17  Sep  92.  This  memorandum  provides 

what  is  included  in  the  requirements  generation  system  process.  * 

e.  Lessons  learned  are  documented  in  the  Automated  Lessons  Learned  Capture  and  Retrieval 
System  (ALLCARS)  maintained  by  ASC/CYM  at  Wright  Patterson  AFB  OH  45433-5000,  DSN  785-3454. 

11.  IMPLEMENTATION  TOOLS:  A  library  of  MNSs  and  ORDs  is  available  in  HO  USAF/XORJ  for 

anyone  who  wants  to  access  them.  For  additional  information,  contact  AFXORJ,  DSN  225-71 07.  • 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Drafting  a  MNS  will  take  30-1 20  working  days,  depending  on  priority. 

b.  CONSTRAINTS:  Product  Center  support  to  the  Operating  Command  during  Mission  Area  • 

Assessment  and  Mission  Needs  Analysis  will  be  done  through  a  process  called  Technical  Planning 

Integrated  Product  Teams  (TPIPTs).  The  process  has  not  been  formalized  and  actually  implemented  to 
date.  It  is  intended  to  combine  Operating  Command  and  Implementing  Command  planning  to  produce 
an  integrated  approach  to  satisfying  mission  needs,  but  is  relatively  untested. 

c.  RESOURCES:  A  dedicated  action  officer  will  require  30-1 20  working  days  to  draft  the  MNS.  • 

Product  Center  personnel  will  become  involved  during  the  technical  planning  team  process  (TPIPTS) 

and  for  identifying  potential  areas  of  study  (materiel  altematives)  for  concept  exploration  and  definition. 
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d.  LESSONS  LEARNED: 

(1)  MNS  writers  sometimes  doni  follow  specific  guidance  provided  on  how  to  write  the  MNS. 
Some  comrrxjn  errors  are  failing  to  reference  the  Defense  Planning  Guidance,  confusing  constraints  with 
requirements,  failing  to  discuss  potential  for  inter-Service  or  allied  cooperation,  and  failing  to  include  the 
threat.  Funding  requirements  will  not  be  included  in  the  MNS. 

(2)  If  the  MNS  has  potential  for  Joint  application,  the  writer  should  contact  the  Office  of  the  Joint 
Chief  of  Staff.  This  office  will  assist  in  coordinating  the  Joint  perspective  from  other  Services  to  create 
one  MNS.  This  could  save  valuable  man-hours  downstream  and  eliminate  some  duplicative  efforts. 

(3)  The  Office  of  the  Joint  Chief  of  Staff  reviews  all  ACAT I  MNS.  Many  times  the  Operating 
Command  identifies  system  requirements  versus  the  need  for  a  materiel  solution.  The  writer  should 
review  MNS  format  and  procedures  prior  to  writing  the  document  to  ensure  it  focuses  on  needs 
expressed  in  broad  operational  capability  terms.  The  MNS  should  not  identify  system  specific 
requirements  or  solutions. 

e.  BEST  PRACTICES: 

(1)  Keep  key  players  (reference  AF1 10-610,  Attachment  10)  involved  and  communications  open 
to  avoid  any  surprises,  ^me  examples  of  surprises  are  not  explaining  the  limitation  in  the  models  used 
in  the  analyses  and  not  understaixfing  the  true  needs  of  the  Operating  Command.  Be  aware  of  the 
consequences  to  specific  decisions. 

(2)  Coordinate  with  other  commands  (Air  Force  MAJCOMs  and  Unified  and  Specified 
Commands)  and  other  Services  to  consolidate  similar  deficiencies  that  can  lower  development  and 
production  costs. 

(3)  Technical  planning  teams  (TPIPTs)  are  being  created  in  AFMC  to  address  mission  areas  at 
least  annually  to  support  the  user  in  determining  specific  tasks  to  perform  and  assess  what  is  available 
and  what  is  feasible.  This  "strategy-to-tasK”  formalizes  how  to  define  requirements  by  reviewing  the 
national  objectives  and  military  strategy,  in  concert.  AFMC  is  in  the  process  of  formalizing  this  process. 
Acquisition  individuals  need  to  become  aware  of  this  process,  who  is  involved,  what  is  accomplished, 
etc.,  in  order  to  understand  how  mission  needs  are  identified  and  evolve  into  potential  solutions  and 
technology  programs  to  support  them. 

f.  TRAPS: 

(1)  Straying  off  the  broad  operational  requirements  and  stipulating  system  specific  solutions 
binding  life  cycle  cost  and  trade-off  analyses.  Pr^uct  Centers  can  assist  by  providing  analyses  in  a  very 
concise  and  standardized  manner.  The  Multiple  Role  Forces  program  is  presently  in  the  process  of 
determining  these  requirements  and  can  be  contacted  for  additional  traps. 

(2)  Delays  in  reviewing  draft  MNS  due  to  priorities  and  availability  of  personnel. 

(3)  Inadequate  data  for  basing  analyses;  not  understanding  the  assumptions  associated  with 
certain  computer  models. 
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1.  ELEMENT:  C13,  TBS  0.2.1 .3  (IFC  93-3) 

2.  ELEMENT  TITLE:  Staff  and  Coordinate  MNS  (User) 

3.  ELEMENT  OWNER:  Operating  Command 

4.  ELEMENT  STAKEHOLOER(S):  Operating  Command,  AFMC,  Participating  Commands,  and 
AF/XOR. 

5.  REQUIREMENT:  AFPD  10-6,  Mission  Needs  and  Operational  Requirements,  19  Jan  93,  Attachment 
3.  identifies  Mission  Need  Statement  (MNS)  approval  requirements.  AF1 10-601 ,  Mission  Needs  and 
Operational  Requirements  Guidance  and  Procedures,  16  Feb  93,  Attachment  4,  identifies  MNS  staffing 
and  coordination  procedures. 

6.  PURPOS&OBJECTIVES: 

a.  Purpose:  Staff  and  coordinate  the  MNS  at  the  Operating  Command. 

b.  Objective:  Obtain  Operating  Command  approval. 

7.  DESCRIPTION:  The  overall  MNS  staffing  and  coordination  process  begins  at  the  Operating 
Command  where  the  MNS  is  drafted  (Cl  2),  continues  with  Air  Staff  coordination  (B7),  JR(X  Senrice, 
CINC,  and  Joint  Staff  coordination  (ACAT  I)  (A6),  and  ends  with  either  CSAF  approval  (ACAT  ll-IV)  or 
validation  and  approval  by  the  JROC  (ACAT  I)  (AS).  The  Air  Staff  and  JROC  will  use  the  latest  threat 
information  to  erasure  the  threat  used  to  develop  the  MNS  is  valid  (B6  and  AS  respectively).  The  JROC 
also  will  review  ACAT  I  MNS  for  assignment  of  Joint  potential  designator  (i.e.,  potential  for  Joint 
applicability).  For  ACAT  ll-IV  MNS,  validation  and  approval  are  done  by  the  Air  Force  with  the  Operating 

9  Command  as  the  validation  authority  and  CSAF  as  the  approval  authority  (JROC  assistance  may  be 

requested  to  resolve  lead  Service  issues).  This  data  sheet  addresses  the  Operating  Command  portion  of 
the  MNS  staffing  and  coordination  process. 

After  the  mission  need  has  been  documented,  the  project  team  will  be  working  with  the  labs  to 
assess  current  technology  and  guide  future  technology  development  (Di8).  The  potential  materiel 
alternatives  identified  in  the  draft  MNS  will  also  be  us^  by  the  project  team  to  plan  for  Phase  0  (Cl  4). 

(Note:  This  data  sheet  addresses  Operating  Command  initiated  MNS.  An  Air  Force  MNS  can  also 
originate  from  other  sources,  including  CINCs,  the  Joint  Staff,  HQ  USAF.  Unified  or  Specified 
Ck>mmands,  and  other  Federal  Agencies  (i.e.,  FAA  or  NASA).  See  AF1 10-601 ,  paragraph  1 .3,  tor  more 
information) 

Validation  confirms  that  a  mission  need  exists  and  cannot  be  satisfied  by  a  nonmateriel  solution. 
Approval  is  the  formal  sanction  that  the  validation  process  is  complete  and  the  need  is  valid.  Approval 
also  indicates  that  the  need  warrants  concept  exploration  studies  for  a  possible  new  acquisition  program. 
After  approval,  the  MNS  is  forwarded  to  the  Milestone  Decision  Authority  for  action. 

Internal  Operating  Command  MNS  coordination  begins  after  the  need  has  been  reviewed  by  a 
requirements  review  group  (4-letter),  approved  by  a  requirements  review  board  (3-letter),  aixJ  a  MNS 
drafted  by  the  functional  action  officer  with  assistance  from  the  Requirements  Directorate  and  other 
experts  as  required.  Other  Service  interest  wilt  normally  be  addressed  during  the  requirements  review 
process.  Criticality  of  the  need  is  the  driving  criteria  for  approval. 
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Internal  coordination  usually  yields  information  on  the  feasibility  of  the  need.  Typical  comments 
might  address  availability  of  furtds,  affordability,  achievabiiity,  or  political  support.  A  Requirements  3- 
letter  office  wilt  be  OPR  for  coordinating  the  MNS.  Internal  coordination  includes  3-letter  and  2-letter 
coordination,  with  time  for  resolution  of  comments  (if  required)  after  each  level.  The  Requirements  DCS 
will  sign  out  the  the  draft  MNS,  and  distribute  for  review  and  comment  outside  the  Operating  Command. 
This  phase  is  referred  to  in  AP1 10-601  as  the  ‘for  comment*  phase.  AP1 10-601 ,  Attachment  10,  lists 
organizations  who  should  review  the  ‘for  comment*  draft  MNS. 

During  the  “for  comriv.-n"  phase,  ACAT  I  MNS  is  distributed  by  AP/XOR  to  the  JROC  Secretariat  for 
Service  staffing.  Por  ACA .  II-IV  MNS,  as  part  of  the  validation  process,  the  Operating  Command  must 
assess  the  Joirrt  potential  of  the  MNS  by  coordinatirrg  with  the  other  Services.  This  is  normally  done  with 
the  help  of  AP/XOR. 

In  response  to  the  request  ‘for  comment,*  organizations  identify  an  OPR  to  the  Operating  Command 
within  7  calendar  days  of  receipt.  Comments  and  proposed  revisions  to  the  draft  MNS  are  provided 
within  45  calerrdar  days  of  receipt,  or  indicated  suspense. 

Comments  from  the  ‘for  commerrt*  phase  are  incorporated  or  resolved  and  a  final  version  is 
prepared  for  3  and  2  letter  final  coordination.  Pinal  comments  are  incorporated  and  the  Operating 
MAJCOM/CC  approves.  The  MNS  is  sent  to  AP/XOR  for  final  Air  Staff  coordination  as  required 
(depending  on  the  severity  of  changes  to  the  “for  comment"  version),  then  CSAP  approval. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance.  When  the  MNS  is  drafted  by  the  Operating  Command. 

b.  Exit:  When  the  MNS  is  approved  by  the  operating  MAJCOM/CC  and  submitted  to  AP/XOR 
for  final  Air  Staff  coordination  and  CSAP  approval. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  draft  MNS  (Cl  2).  Current  threat  information  from  AP/IN  (B6),  validated  by  DIA 
(ACAT  I)  (A5),  to  ensure  the  threat  used  to  develop  the  MNS  will  remain  valid  up  to  CSAP  approval. 

b.  Outputs:  An  operating  MAJCOM/CC  approved  MNS  that  is  forwarded  to  the  Air  Staff  for  CSAP 
approval  (B7).  Technology  guidance  to  the  labs  through  the  project  office  (D18).  Information  on 
potential  materiel  alternatives  will  be  used  to  begin  Phase  0  planning  (Cl 4). 

10.  KEY  REFERENCES:  See  Requirement,  paragrai;^  5. 

11.  IMPLEMENTATION  TOOLS:  Local  Operating  Command  instructions. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  following  schedule  for  staffing  and  coordinating  the  MNS  is  ‘success  oriented." 
It  leaves  very  little  room  for  mistakes.  The  need  for  additional  time  (2  or  3  morrths)  is  not  unusual, 
especially  if  there  is  no  high-powered  interest  in  facilitating  coordination: 

Internal  Operating  Command  3-letter  draft  coordination: 

15  days  (review) 

5  days  (resolve  comments) 
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Internal  operating  command  2-lelter  draft  coordination; 

5  days  (review) 

3  days  (resolve  comments) 

Print  and  mail: 

5  days 

External  draft  for  comment’  phase: 

52  days  (review) 

1 5  days  (resolve  comments) 

Internal  Operating  Command  3-letter  final  coordination: 

5  days  (review) 

3  days  (resolve  comments) 

Internal  Operating  Command  2-letter  final  coordination; 

5  days  (review) 

3  days  (resolve  comments) 

Internal  Operating  Command  Council  Review  (ACAT I  or  by  request); 

15  days 

Internal  operating  MAJCOM/CC  signature: 

5  days 

Total  duration  1 36  days 

b.  CONSTRAINTS:  None  identified. 

c.  RESOURCES:  An  Operating  Command  OPR  will  (maybe  more  than  one  depending  on  size  and 
visibility  of  the  program)  plan,  initiate,  and  conduct  the  staffing  and  coordination  process.  Normally  the 
Operating  Command  OPR  will  be  someone  from  the  Requirements  DCS  supported  by  a  mission  area  or 
functional  OCR.  An  OPR  will  be  required  from  each  organization  (i.e.,  AFMC,  Product  Center)  to  staff 
and  coordinate  the  MNS.  Functional  points  of  contact  will  be  needed  to  review  and  comment. 

d.  LESSO^e  LEARNED: 

(1)  This  activity  is  handled  by  the  Operating  Command  OPR.  Product  Center  involvement 
normally  would  have  occurred  prior  to  staffing  and  coordination,  hopefully  in  support  of  the  Mission  Need 
Analysis  and  development  of  the  MNS.  If  major  issues  arise  during  this  activity,  however,  the  Operating 
Command  OPR  would  notify  major  stakeholders  and  resolve  the  issues. 
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(2)  The  MNS  OPR  at  the  Operating  Command  normally  has  his  hands  full  getting  the  document 
to  the  right  people  and  ensuring  tasked  organizations  return  comments  on  time.  He  wiH  carefuHy  plan 
the  staffing  and  coordination  schedule  and  build  in  plenty  of  slack  time,  especially  for  potentially 
controversial  programs,  to  ensure  a  quality  review  can  be  done. 

(3)  Product  Center  OPRs  should  take  the  time  to  ensure  the  MNS  is  a  quality  document:  (1 ) 

Pay  special  attention  to  whether  the  MNS  is  properly  focused  on  needs,  not  solutions.  (2)  Confirm  that 
the  need  is  real  and  based  on  the  current  threat.  (3)  Challenge  system  specific  requirements  or 
unsubstantiated  required  capability  dates.  (4)  Ensure  alt  constraints  have  been  identified.  (5)  Ensure  the 
MNS  does  not  evaluate  potential  alternatives. 

With  all  the  coordination  and  working  of  comments,  there  are  bound  to  be  obstacles  that  require 
extraordinary  effort  to  overcome,  such  as  unforeseen  issues,  kjrf  battles,  and  other  differences  of 
opinion.  This  is  particularly  true  lor  potential  Joint  needs. 

e.  BEST  PRACTICES: 

(1)  The  Operating  Command  OPR  normally  will  involve  all  stakeholders  in  the  review  and 
coordination  process.  He'll  be  keeping  the  AF/XOR  POC  in  the  loop  and  be  working  off  the  same 
validation  and  approval  schedule.  Early  involvement  of  the  Joint  Staff  is  especially  important  for 
potential  ACAT I  MNS.  The  Product  Center  OPR  also  has  stakeholders  that  shouldnl  be  left  out.  An 
important  stakeholder  (e.g..  Product  Center  development  planners)  who  dkjnl  get  to  comment  can  come 
back  to  haunt  you. 

(2)  The  action  officer  can  establish  a  sunset  clause  for  comments  and  coordination.  However, 
the  Operating  Command  OPR  will  normally  wait  for  comments  from  critical  organizations  like  AF/XOR, 
AFMC,  AETC  and  AFOTEC  before  proceeding  on  to  the  next  phase.  The  OPR  will  be  following  up  on 
comments  or  coordination  needed  the  most,  and  will  ensure  the  MNS  action  was  received  and  is  being 
worked  according  to  schedule. 

(3)  The  Product  Center  OPR  should  be  prepared  to  help  the  Operating  Command  OPR  work 
any  comments  received. 

f.  TRAPS: 

(1)  The  MNS  OPR,  for  any  organization,  shouldn't  assume  all  organizations  wilt  respond  on 
time.  In  order  to  stay  on  schedule,  he  should  stay  in  close  touch  with  the  organizations  whose 
coordination  or  cooperation  are  needed  the  most  (long  poles). 

(2)  While  schedule  may  be  a  good  motivator  for  getting  the  job  done,  it  may  inhibit  a  quality 
review.  This  activity  should  be  primarily  concerned  about  getting  a  quality  review.  Strike  the  right 
balance. 
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1.  ELEMENT:  C14,  TBS  1.1 .1.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Develop  Draft  Phase  0  Plans  (Lead  MAJCOM) 

3.  ELEMENT  OWNER(S):  Lead  Major  Command  (MAJCOM)  as  designated  by  USAF/XOR.  For  Air 
Force  led  Phase  0  efforts,  the  lead  MAJCOM  is  typically  an  Orating  Command. 

4.  ELEMENT  STAKEHOLDER(S):  Air  Staff  (USAF/XOR.  SAF/AQX).Operating  Command(s).  Air  Force 
Materiel  Command  (AFMC/CC.  XR).  and  AFMC  Product  and  Air  Logistics  Centers  (PCs/ALCs). 

5.  REQUIREMENT 

a.  AF  Regulation  800-1 . 16  Feb  90.  "Air  Force  Acquisition  System.*  paragraph  5.c.  identifies  the 
acquisition  management  responsibilities  of  Air  Force  acquisition  managers. 

b.  AF  Instruction  10-601 . 1  Oct  92.  'Mission  Needs  and  Operational  Requirements  Guidance 
arKi  Procedures."  Attachment  2.  identifies  the  Major  Command  (MAJCOM)  and  Field  Operating  Agency 
(FOA)  pre-Milestone  I  responsibilities. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  To  determine  the  Air  Force  Concept  Exploration  and  Definition  (Phase  0)  planning 
position. 

b.  Objective;  To  identify  and  document  the  following  planning  information  to  prepare  for  Phase 
0  and  possibly  support  a  Milestone  0  decision; 

Phase  0  purpose,  objectives,  constraints,  and  assumptions. 

The  proposed  strategy  and  organization  for  accomplishing  Phase  0. 

Estimates  of  the  required  schedule  and  resources  needed  to  accomplish  Phase  0. 
Content  recommerxlations  for  the  Phase  0  Acquisition  Decision  Memorandum  (ADM) 
and  Program  Management  Directive  (PMD). 

7.  DESCRIPTION:  After  the  Operating  Command  has  identified  an  operational  need  that  cannot  be  met 
through  nonmateriel  means,  a  Mission  Need  Statement  (MNS)  will  be  written  and  forwarded  for  review 
and  approval  to  proceed  with  Concept  Exploration  and  Definition  (CE/D  or  Phase  0).  At  this  point  the 
lead  MAJCOM  should  initiate  planning  activities  to  identify  the  desired  participants,  strategy, 
organizational  structure  and  relationships,  and  associated  costs  for  Phase  0.  The  Phase  0  planning 
activities  must  be  a  coordinated  effort  between  all  of  the  organizations  expected  to  implement  the  plans 
when  approved.  The  lead  MAJCOM  is  responsible  for  ensuring  the  coordination  of  the  Phase  0  planning 
efforts  of  each  of  the  implementing  organizations  and  formulating  the  proposed  Air  Force  position  on 
how  Phase  0  will  be  accomplished. 

8.  ENTRANCE  AND  EXIT  CRITERIA: 

a.  Entrance: 

MAJCOM  /CC  Direction  to  Proceed  to  Milestone  0  -  The  Operating  Command 
determines  they  have  an  operational  need  that  they  do  not  believe  can  be  satisfied  by  nonmateriel 
means.  They  decide  a  MNS  must  be  written  and  request  an  Air  Force  decision  through  USAF/XOR  to 
proceed  to  a  Milestone  0  decision. 
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b.  Exit;  When  the  Milestone  Decision  Authority  (MOA)  is  satisfied  with  the  MNS  and  any 
requested  Phase  0  planning  information,  approval  is  given  to  proceed  with  Phase  0  concept  Judies.  The 
MDA  will  issue  an  ADM,  and  AF/XOR  wiN  issue  a  PMD.  After  receiving  these  documents  the  lead 
MAJCOM,  in  partnership  with  the  acquisKion  community,  should  update  Air  Force  Phase  0  plans  as 
required  to  br^  them  in  line  with  the  guidance  provided  by  the  ADM  and  PMD  (see  C1 6,  D22.  and  D23). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  MNS(see  C12,  C13,  B7,  A6,  and  AS)  - 'Rie  MNS  is  the  driving  force  behind 
understanding  the  purpose  and  need  for  the  Phase  0  activities.  The  lead  MAJCOM  should  begin 
planning  for  Phase  0  as  soon  as  a  draft  MNS  is  available  from  the  operating  command.  The  lead 
MAXOM  should  always  be  using  the  most  current  MNS  as  it  passes  through  successive  levels  of 
reviews  and  coordinations,  approval,  and  validation. 

(2)  Acquisition  Community  Inputs  (see  D20A)  -  The  lead  MAJCOM  must  place  a  heavy 
reliance  on  government  acquisition  agencies,  and  contractors  as  appropriate,  to  plan  and  execute  the 
activities  required  to  meet  Phase  0  objectives.  Planning  inputs  must  be  collected  from  all  organizations 
that  will  be  providing  acquisition  management  and/or  technical  support  to  the  lead  MAJCOM  for  Phase  0. 

b.  Outputs: 

[NOTE:  After  the  output  information  discussed  below  has  been  developed,  it  should  be  documented  and 
coordinated  with  all  supporting  organizations  (such  as  the  PC/ALCs,  AFSAA,  USAF/IN,  etc.)  before  being 
forwarded  for  coordination  and/or  approval  by  the  Air  Force  or  appropriate  approval  authority.  The  'Best 
Pctices*  section  of  this  document  provides  an  approach  to  documenting  the  Phase  0  plans.  This 
documentation  can  also  serve  to  support  the  lead  MAJCOM's  inputs  to  the  Program  Management 
Directive  (PMD)  and  the  Acquisition  Decision  Memorandum  (ADM),  if  it  chooses  to,  or  is  asked  to,  be 
actively  involved  with  their  development.] 

(1)  Phase  0  Purpose,  Objectives,  Constraints,  and  Assumptions: 

(a)  Purpose  •  The  stated  pja  ose  of  the  Phase  0  activities  must  be  consistent 
with  the  MNS.  It  should  provide  background  informath  n  on  the  decision  process  that  led  to  initiation  of 
the  Phase  0  planning  and  describe  why  the  Phase  0  activities  are  necessary. 

(b)  Objectives  -  The  lead  MAJCOM,  in  partnership  with  the  acquisition 
community,  will  identify  all  objectives  of  the  Phase  0  activities  and  provide  them  to  all  supporting 
government  agencies  and  contractors.  Objectives  state  the  desired  results  of  the  Phase  0  activities. 
Objectives  are  convnitments,  not  wishes.  Objectives  are  not  the  activities,  but  the  irrtended  end  results. 
Activities  are  the  steps  to  be  taken  to  achieve  the  objectives.  All  objectives  must  be  identified,  otherwise 
the  resources  and  time  needed  to  achieve  them  will  not  be  account^  for  in  the  planning  inputs  from  the 
supporting  government  agencies  and  contractors. 

(c)  Constraints  -  The  lead  MAJCOM  and  all  participating  agencies  should 
identify  known  or  anticipated  constraints.  The  lead  MAJCOM  will  compile  a  list  of  constraints  and 
assumptions  and  provide  it  to  all  supporting  government  agencies  and  contractors,  as  appropriate,  so 
they  can  be  accounted  for  in  the  planning  process.  Constraints  include  any  limitations  and/or  needs 
regarding  characteristics  of  the  Phase  0  p^ucts  to  be  ii^oduced,  the  schedule  for  performing  Phase  0, 
the  experience  level  and/or  types  of  resources  needed  and  available,  and  the  way  in  which  specified 
tasks  can  be  performed.  Limitations  are  conditions  placed  on  supporting  government  agertcies  and/or 
contractors,  to  which  they  must  conform  when  executing  given  tasks.  Needs  are  conditions  the  lead 
MAJCOM  stipulates  must  be  met  to  allow  successful  project  completion  (i.e.  exK  criteria). 
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(d)  Assumfftions  -  An  assumf^ion  is  any  condition  or  situation  which  is  taken  to 
be  true,  but  which  cannot  be  verified  as  being  true  with  certainty.  Any  assumptk^  made  when 
preparing  the  Phase  0  Plan,  either  by  the  lead  MAXOM  or  supporting  organizations,  should  be  written 
down  and  monitored  by  the  lead  MAJCOM  during  project  execution.  If  an  assumption  eventually  turns 
out  to  be  false,  the  lead  MAJCOM  rrust  work  with  the  supporting  government  agencies  arxl  contractors 
to  determine  the  impact  on  the  project.  Typically  assumptions  might  be  made  regarding  objectives, 
schedules,  availabikty  of  requir^  resources,  wc^  to  be  performed,  and/or  organizational  situations  or 
conditions. 


(2)  Phase  0  Strategy  and  Organization: 

(a)  Strategy-  The  strategy  should  discuss  the  overall  busirtess  and  technical 
approaches  to  be  taken  by  the  Air  Force  to  accomplish  Phase  0.  It  should  specificaliy  bound  the  scope 
of  the  work  to  be  performed  and  identify  the  major  activities  to  be  completed  to  satisfy  afl  Phase  0 
objectives.  The  strategy  should  identify  any  other  projects  or  programs  with  which  the  Phase  0  activfties 
migM  irMerface  (Phase  0  munitnns  projects  might  interface  with  various  platform  programs  for  instance) 
and  to  what  extent  other  Services  and/or  foreign  countries  wiH  participate  in  Phase  0.  The  extent  to 
which  industry  will  be  involved,  and  how  they  wilt  be  reimbursed  for  their  efforts,  should  also  be 
addressed.  Depending  on  the  significance  of  the  Phase  0  project,  the  lead  MAJCOM  or  USAF/XOR  nuiy 
want  to  convene  an  Air  Force  Acquisition  Strategy  Panel  (ASP)  to  review  and  approve  the  proposed 
Phase  0  strategy. 


(b)  Organization  -  The  lead  MAJCOM  should  identify  all  required  project 
participants  and  how  they  will  be  organized  to  accomplish  the  work  required  to  achieve  Phase  0 
objectives.  Organizational  responsibilities  should  be  assigned  and  agreed  to  through  a  Memorandum  of 
Agreement  (MOA)  or  other  commitment  document,  if  any  steering  or  working  groups  will  be  formed, 
their  roles  and  responsibilities  should  be  identified  and  an  OPR  assigned  to  ensure  their  timely  formation 
(seeC16). 


(3)  Phase  0  Schedule  and  Resource  Requirements  •  The  lead  MAJCOM,  working  with 
the  acquisition  community,  should  identify  the  overall  schedule  and  associated  resources  required  to 
achieve  Phase  0  objectives,  given  the  proposed  strategy.  Both  should  be  derived  from  the  Phase  0 
planning  inputs  provided  by  supporting  government  and  industry  organizations.  The  schedule  should  be 
based  upon  resource  availability  and  the  accomplishment  of  key  events,  or  milestones,  and  not  driven  by 
caletKlar  dates.  Required  resources  should  include  personnel,  funding,  software/models,  equipment, 
facilities,  materiel,  and  information.  Estimated  Phase  0  funding  requirements  must  be  provided  to  the 
Operating  Oimmancfs  financial  management  organization  to  develop  a  budget  request  (see  Cl  5). 

(4)  ADM  and  PMD  Inputs  -  It  is  in  the  best  interest  of  the  lead  MAJCOM,  working  with 
the  acquisition  community,  to  submit  recommendations  to  USAF/XOR  regarding  the  content  of  the 
Phase  0  ADM  and  the  PMD.  The  key  outputs  listed  above,  along  with  the  MNS,  will  provide  all  of  the 
recommendations  required  for  the  MDA  to  write  the  Milestone  0  ADM  (see  A9)  and  for  USAF/XOR  to 
write  the  Phase  0  PMD  (see  BIO). 

10.  KEY  REFERENCES: 

a.  DoD  Directive  5000.1 , 23  Feb  91 ,  'Defense  Acquisition,’  provides  overall  DoD  defense 
acquisition  policies. 

b.  DoD  Instruction  5000.2, 23  Feb  91 ,  'Defense  Acquisition  Management  Policies  and 
Procedures,’  Section  E,  paragraph  2,  provides  DoD  policies  on  program  plans. 


«) 


Ar; 


•  • 


D-209 


NdwM 


c.  AF  Poticy  Letter  91M-001 , 20  91 ,  ’Early  Irvlustry  Invotvement  in  Acquisition  Ranning  ‘ 

establishes  SAP  policies  regarding  early  Industry  involvement  in  acquisition  plannirtg. 

11.  IMPLEMENTATION  TOOLS:  See  D20  for  information  on  potential  implementation  tools  to  support 
this  activitiy. 

12.  PLANNING  GUIDANCE 

a.  DURATION  -  The  duration  of  the  Phase  0  planning  activities  wiN  vary  depending  on  a  variety 
of  factors  such  as  potential  program  size,  complexity,  available  resources,  political  sensitivtty,  number  of 
organizations  involved.  Joint  service  and/or  international  irtvolvemeni,  etc.  The  major  driver  will  Hkely  be 
the  number  of  organizations  involved  since  thorough  coordination  of  aH  aspects  of  the  plan  is  required  to 
have  a  high  confidence  in  its  executability.  For  fairly  simple  Phase  0  efforts,  a  minimum  of  about  3 
months  should  be  allowed  to  build  and  coordinate  planning  information.  For  potential  DAB  programs, 
adequate  planning  and  coordination  could  take  as  much  as  1  year. 

b.  CONSTRAINTS:  None  identified. 

c.  RESOURCES: 

(1 )  Manpower  -  To  develop  the  Phase  0  plan,  the  lead  MAJCOM  must  engage  the 
support  of  all  organizations  expected  to  play  a  major  role.  This  will  typically  include  personnel  from 
USAF/XOR,  SAF/AQ,  AFMC  PCs/ALCs,  the  Office  of  Aerospace  Studies  (OAS),  and  other  MAJCOM 
organizations.  If  there  are  Joint  Sennce  or  international  implications,  then  personnel  from  those 
organizations  must  also  be  involved.  If  the  Phase  0  activities  will  require  access  to  and/or  generation  of 
special  access  materials,  security  personnel  from  SAF/AQ  must  be  assigned. 

(2)  Funding  -  Sufficient  funding  should  be  made  available  to  allow  necessary  arxJ 
appropriate  travel  lor  collecting  and  coordinating  planning  inputs  from/with  participating  organizations. 

(3)  Other  Resource  Considerations  ■  If  the  Phase  0  activities  will  require  access  to 
and/or  generation  of  special  access  information,  then  a  special  access  program  must  be  generated  and 
facilities  must  be  made  available  at  all  impacted  support  installations.  All  special  access  programs 
required  to  support  Air  Force  pre-Milestone  I  activities  are  requested  through  USAF/XOR.  /Vt  least  6 
nronths  lead-time  should  be  allowed  to  establish  a  special  access  program. 

d.  LESSONS  LEARNED:  None  Identified. 

e.  BEST  PRACTICES: 

(1)  Initiate  a  Working  Group  to  He^  Plan  tor  Phase  0  -  For  larger  Phase  0  projects,  it 
may  be  beneficial  for  the  lead  MAJCOM  to  initiate  a  working  group  to  help  integrate  organizational  plans 
into  a  single  Air  Force  Phase  0  planning  position.  This  group  should  contain  representation  from  all  of 
the  organizations  critical  to  the  achievement  of  the  Phase  0  objectives.  The  working  group  objective 
would  be  to  integrate  all  of  the  Phase  0  planning  inputs  from  each  of  the  organizations  expect^  to 
participate  in  Phase  0  and  develop  a  single  recommended  Air  Force  position  on  how  to  accomplish 
Phase  0. 


(2)  Develop  a  Master  Plan  and  Master  Schedule  •  The  lead  MAJCOM  should  develop  a 
master  plan  and  schedule  that  documents  the  coordinated  Air  Force  planning  position  and  incorporates 
the  plans  and  schedules  of  each  of  the  implementing  organizations.  Schedules  should  be  event-based 
with  clearly  defined  success/exit  criteria  for  proceeding  to  the  next  established  event.  See  D20  for  more 
details  on  the  Master  Plan  and  Master  Schedule  concepts. 
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(3)  BuHd  an  Earty  Partners/ip  with  industry  -  It  is  Air  Force  policy  (see  AFP  91  M-(X)1 )  to 
facilitate  early,  open,  and  effective  communications  between  industry  and  government  during  the 
acquisition  planning  process.  This  early  communication  is  vital  to  achieving  ultimate  program  success. 
Industry  participation  in  Pre-MS  0  activities  can  be  a  great  benefit  for  both  the  government  and  the 
irvAiStry  participants.  The  Government  can  readily  tap  years  of  industry  independent  research  and 
developtnent  (IRAQ)  and  impact  future  industry  IR&D  spending  or  sch^ling  plans.  Industry  can  gain 
insight  to  early  Gov^ment  planrring  information  to  develop  better  bng  range  plans  and  put  themselves 
in  a  better  competitive  position  if  an  acquisition  program  actually  does  develop. 

f.  TRAPS: 

( 1 )  Use  of  Industry  Information  -  Because  industry  provided  information/data  is  often 
misrepresented  or  misleading,  it  is  critical  that  experienced  acquisition  personnel  play  key  roles  in  any 
eftort  that  includes  industry  developed  or  provided  information.  Industry  provided  data  should  not  be 
taken  at  face  value  and  should  always  be  examined  for  legitimacy. 

(2)  Lead  MAJCOM  Desire  to  Proceed  Forward  too  Rapidly  -  Many  lead  M  AJCOM  action 
officers  do  not  understand  the  many  successful,  logically  based,  event-driven  steps  that  must  occur  to 
achieve  Phase  0  objectives.  The  Irad  MAJCOM  should  avoid  establishing  unreasonable  timelines  that 
drive  the  planning  activities  or  the  Phase  0  activities  and  schedules. 

(3)  Optimistic  Planning  -  The  lead  MAJCOM  should  not  allow  overly  optimistic  schedule 
and  resource  planning  to  occur,  either  by  themselves  or  any  of  their  supporting  organizations  (i.e., 
PC/ALCs,  industry,  support  contractors,  etc.).  Because  there  is  insufficient  resources  available  to  cover 
all  the  programs  the  MAJCOM  feels  they  need  to  support  is  not  an  excuse  for  planning  for  bare-bones 
resources.  Nor  is  headquarters  direction  to  complete  an  activity  by  a  given  date  an  excuse  to  plan  to 
that  date  if  it  cant  be  achieved  given  available  resources;  negotiate  a  more  reasonable  completion  date 
or  get  a  commitment  for  the  required  resources.  If  you  know  your  plans  are  optimistic  (versus  realistic), 
you're  simply  setting  yourself  up  for  failure. 
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1.  ELEMEHT:  CIS,  TBS  1.1.1.5.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Update  Budget  Request 

3.  ELEMENT  OWNER(S):  Using  Commands 

4.  ELEMENT  STAKEHOLOER(S):  SAFfAQ/RAB,  AF/XOR.  AFMC/XR,  ASC/XR/YX,  and  HQ 
AFMC/XT/FM. 

5.  RECMJIREMENT:  OoO  Directive  7045.14,  The  Planning,  Progranwning,  and  Budget  System  (PPBS), 
22  May  84.  This  directive  provides  guidelines  tor  updating  a  program  funding  line  in  the  PPBS  cycle. 

6.  PURPOSE/OBJECTIVE(S): 

a.  The  purpose  of  this  element  is  to  update  the  existing  project  funding  level  in  the  PPBS. 

b.  The  objective  is  to  provide  adequate  project  funding  over  the  6-year  budget  cycle. 

7.  DESCRIPTION:  Once  the  Air  Force  has  determined  that  a  material  solution  is  required  and  the  usirrg 
Major  Command  (MAJCOM)  has  documented  the  requiremertt  with  a  Mission  Need  Statement  (MNS) 
(C13),  the  user  then  develops  a  plan  for  Phase  0  ( C14  and  D20a).  Funding  for  this  new  start  is 
generally  supplied  by  Program  Element  (PE)  65808  or  a  PE  with  related  projects. 

The  using  MAJCOM  point  of  contact  may  or  may  not  establish  a  Studies  Advisory  Group  (SAG) 
(C4).  The  ASC  project  manager  works  with  the  SAG  or  project  officer  to  identify  what  project  activities 
are  planned  during  the  POM/BES  years.  The  ASC  project  office  will  be  tasked  to  estimate  how  much  the 
proj^  will  cost  and  to  prepare  a  POM/BES  input.  The  AFSC  Financial  Management  Handbook, 

Ch^er  1 ,  provides  more  information  on  the  AFMC  role  in  the  POM/BES  process  and  how  the  using 
MAJCOM  is  supported. 

After  the  ASC  project  officer  prepares  the  cost  estimate  and  the  MAJCOM  POM/BES  is  ready  to 
be  submitted  to  Air  Staff  (B8),  it  must  be  reviewed  and  approved  by  the  user.  If  the  MAJCOM  has  not 
established  a  SAG,  it  is  recommended  that  a  review  and  buy-in  be  conducted  by  the  using  MAJCOM 
POC,  POM  focal  point  and  comptroller  cost  analysis  function. 

The  PPBS  Primer,  Tlh  edition,  Jan  93,  Chapter  4.2.3,  provides  more  information  on  the 
MAJCOM  POM  Development  process. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  effort  described  above  can  only  be  executed  if  there  is  an  established  funding 
line  in  the  POM/BES  to  support  this  project. 

b.  Exit;  Update  of  the  Air  Force  POM/BES. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1 )  Update  Phase  0  cost  estimate  and  its  associated  groundrules  and  assumptions 
(D20a). 

(2)  Air  Force  decision  to  pursue  material  solution  (C7). 

(3)  MNS  should  be  completed  by  user  (C13). 

b.  Outputs: 
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POM  submission  to  AF/XOR  (B8). 

BES  submission  to  SAF/FMB  (B8). 

ia  KEY  REFERENCES:  The  following  documents  provide  infomnation  on  the  Bienreal  Programming, 
Planning,  and  Budgeting  System(BPPBS): 

a.  OoOl  7045.7,  Implementation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 
23  May  84. 

b.  AFP  1 72-4,  The  Air  Force  Budget  Process,  Oct  87. 

c.  POM  Guidance,  issued  bi-annually  from  AF/PE,  usually  around  June  of  odd  numbered  years. 

d.  AFSC  Financial  Management  Handbook,  Chapter  1 ,  Nov  92. 

11.  IMPLEMENTATION  TOOLS:  The  PPBS  Primer,*  7th  Edition,  Jan  93.  This  documem,  while  still 
'draft,'  is  published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and 
provides  a  valuable  description  of  the  current  PPBS  process.  This  is  one  of  the  few  documents  that 
describes  the  current  process,  and  it  does  so  in  detail.  Further,  it  defines  the  activity  schedule  tor  the 
development  of  the  POM. 

12.  PLANNING  GUIDANCE: 

a.  Duration;  Approximately  9  months.  Normally  the  POM  process  starts  in  the  spring  of  odd 
numbered  years  when  the  Air  Staff  provides  each  MAJCOM  with  a  current  repriced  AF  baseline  and  a 
MAJCOM-specific  baseline.  In  the  fall  of  the  odd  numbered  years,  the  MAJCOMs  present  their  POM 
proposals  to  HQ  USAF.  ASC  involvement  usually  starts  in  June  and  continues  through  September. 

b.  Constraints: 

(1 )  The  supporting  cost  estimate  will  have  to  be  done  at  a  very  high  level  because  very 
little  is  krxTwn  about  how  the  program  will  be  stnjctured.  Because  of  this,  the  estimate  should  only 
address  the  POM  years.  The  whole  purpose  of  an  estimate  and  a  POM  at  this  time  is  just  to  ensure 
project  funding  is  available  when  a  favo^le  MS  0  decision  is  made. 

(2)  The  using  MAXOM  will  have  to  prioritize  their  requirements.  As  the  budget 
becomes  tighter  during  this  drawdown  period,  hard  choices  will  have  to  made  if  new  starts  are  to  receive 
funding. 
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c.  Constraints:  The  ASC  project  manager  needs  to  stay  in  constant  contact  with  the  MAJCOM 
POC  and  the  Program  Element  Monitor  (PEM).  The  PEM  is  the  Air  Force  overall  focal  point  for  his  or 
her  programs  and  must  interface  with  the  Resource  Allocation  Team  to  ensure  his  Program  Element 
(PE)  is  supported  property.  A  few  weeks  of  the  project  manager's  and  cost  analyst's  time  may  be 
required  to  prepare  the  POM  input  and  answer  what-ifs  and  other  questions. 

d.  Lessons  Learned:  During  the  Air  Staff  POM  delfoerations  and  reviews,  it  is  important  that  the 
project  maru^ers  keep  in  close  contact  with  the  project  representattve(s)  in  AF/XO  (and  SAF/AQ,  if 
someone  has  been  id^ified).  This  is  important  to  help  resolve  issues  that  may  arise,  and  to  ensure  that 
they  fully  understand  all  the  pertinent  aspects  of  the  project,  and  can  defend  the  projected  resource 
requirements.  Also,  develof^nt  of  the  POM  is  a  comprehensive  and  complex  task,  and  the 
information  requested  can  expected  to  change  wKh  every  submission.  Therefore,  the  POM  focal 
point  in  the  prefect  office  needs  to  ensure  that  (s)he  is  not  only  in  compliance  with  the  formal  tasking  and 
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the  local  budget  staff  instructions,  but  also  satisfies  the  information  and  documentation  needs  the  Air 
Staff  project  representative. 

e.  Best  Practices;  After  submission  of  the  POM  package,  the  project  office  should  posture  itself 
to  be  able  to  respond  effectively  to  programnfuttic  questions,  and  to  be  able  to  generate  quantftative 
answers  to  Air  Staff  requests  to  develop  and  price  out  program  variations  to  the  POM  subrrassion.  The 
capability  to  generate  this  'what-if  information  in  a  tiniely  (and  quality)  manner  is  important,  since  the 
recoTKiliations  and  rankings  to  be  performed  by  the  Resource  AHocation  Teams  may  require 
modificatiorrs  to  the  MAJCOM  POM  requests  arto  programs  in  terms  of  fundmg  lev^,  quantities, 
schedules,  or  other  programmatic  aspects.  If  a  project  office  is  unable  to  provide  the  necessary 
information  in  time  to  supf>ort  the  decision  makers,  the  project  may  not  supported  or  approved 
withsufficient  funding  lev^s.  Get  AF/AQ  involved  as  early  as  possible. 

f.  Traps: 

(1 )  Lack  of  clear  explanation/documentation  that  this  budget  wedge  is  anything  more 
than  just  an  initial  budget  line  and  isn1  backed  up  by  an  estimate  of  a  real  program  (i.e.,  estimate  doesnl 
represent  a  full  estimate  of  the  anticipated  program)  Sometimes  these  estimates  can  become  engraved 
in  stone  even  before  an  official  approach  has  been  agreed  on  (i.e..  new  aircraft  or  mod  existirrg  aircraft): 
that's  why  we  recommend  only  estimating  from  MS  0  decision  through  POM  years. 

(2)  If  the  POM  is  the  first  for  the  project,  the  submission  will  be  considered  a  "New 
Start,"  and  identified  as  such.  There  may  be  additional  documentation  requirements  arto  a  higher  level 
of  review  for  these  programs,  since  there  is  not  an  existing  funding  line.  Due  to  this,  the  project  office 
must  be  especially  prepared  to  defend  project  requirements. 
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1.  ELEMENT:  C16.  TBS  1.1. 4.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Update  Phase  0  Plans  (Lead  MAJCOM) 

3.  ELEMENT  OWNER(S):  Lead  Major  Command  (MAJCOM)  as  designated  by  the  Phase  0  PMD.  For 
Air  Force-led  Phase  0  efforts,  the  lead  MAJCOM  is  typically  one  of  the  Operating  Commands. 

4.  ELEMENT  STAKEHOLDER(S)  Air  Staff  (USAF/XOR/TEP/INX,  SAF/AQX/FMC),  Operating 
Command(s),  Air  Force  Materiel  Command  (AFMC/CC,  XR).  AFMC  Product  and  Air  Logistics  Centers 
(PCs/ALCs). 

5.  REQUIREMENT: 

AF  Regulation  800-1 , 1 6  Feb  90,  "Air  Force  Acquisition  System,*  paragraph  S.c,  identifies  the  acquisition 
management  responsibilities  of  Air  Force  acquisition  managers. 

AF  Instruction  1 0-601 , 1  Oct  92,  “Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,"  Attachment  2,  identifies  the  Major  Command  (MAJCOM)  and  Reid  Operaiing  Agency 
(FOA)  pre-Milestone  I  responsibilities. 

6.  PURPOS&OBJECTIVE(S): 

a.  Purpose;  To  complete  Phase  0  planning  and  organize  to  execute  the  Milestone  Decision 
Authority  (MDA)  Phase  0  direction  as  provided  through  the  Acquisition  Decision  Menwrandum  (ADM) 
and  the  Program  Management  Directive  (PMD). 

b.  Objective(s): 

(1 )  Phase  0  Plans  Approval  -  After  updating  the  Phase  0  plans  to  account  for  PMD 
direction,  the  lead  MAJCOM  should  obtain  appropriate  approval(s)  before  executing  the  plans.  The 
appropriate  level(s)  of  approval  will  depend  on  the  significance  of  the  activity  and  should  be  addressed 
by  the  Phase  0  PMD. 

(2)  Establish  Required/Desired  Steering  and  Working  Groups  -  The  lead  MAJCOM  may 
be  directed  by  the  PMD,  or  may  want,  to  establish  some  steering  or  working  groups  to  help  direct, 
manage,  or  execute  some  of  the  lead  MAJCOM  Phase  0  responsibilities. 

7.  DESCRIPTION: 

a.  Updating  the  Phase  0  Plans  -  Upon  the  completion  of  the  Milestone  0  reviews  and  MDA 
approval  of  concept  study  efforts,  the  MDA  issues  an  ADM  (see  A9  and  B9).  After  receipt  of  the  ADM, 
USAF/XOR  completes  and  issues  the  Phase  0  PMD  (see  BIO).  The  lead  MAJCOM  must  ensure  the 
previously  developed  Phase  0  plans  (see  Cl  4  and  D20)  satisfy  the  direction  provided  by  the  ADM  and 
the  PMD,  as  issued.  If  the  lead  MAJCOM  was  actively  involved  with  the  drafting  of  the  ADM  and  PMD, 
and  proactive  at  addressing  issues  raised  throughout  the  Milestone  Review  process,  there  should  be  no 
surprises  regarding  the  content  of  either  document.  In  this  case,  the  draft  plans  devebped  during  the  the 
Milestone  Review  process  should  need  little  or  no  modificatbn,  and  may  be  ready  for  immediate 
implementation.  After  any  needed  modificatbns  have  been  completed,  final  coordinatbn  is  obtained 
from  all  participating  organizatbns,  and  final  approval  of  the  plans  is  made  by  the  appropriate  approval 
authority,  as  established  by  the  PMD.  Upon  final  approval,  the  plans  are  baselined  and  used  by  the  lead 
MAJCOM  and  all  partbipating  organizations  as  the  basis  br  executing  and  controlling  all  Phase  0 
activities.  Throughout  Phase  0,  changes  in  directbn,  strat^,  resources,  etc.,  must  be  monitored  and 
evaluated  by  the  lead  MAJCOM  and  appropriate  partbipating  organizatbns  for  their  impact  to  the 
baseline  plans.  For  significant  changes,  the  plans  may  need  to  be  reworked,  recoordinated  and 
approved,  and  then  rebaselined. 
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b.  Estsdjiishing  the  Steering  and  Working  Groups  -  During  the  Milestone  Review  process,  the 
lead  MAJCOM  should  have  begun  organizing  the  resources  needed  to  achieve  the  Phase  0  objectives. 
This  activity  includes  the  identification  and  establishment  of  any  desired  or  required  steering  and/or 
working  groups.  Steering  and  working  groups  are  one-time,  periodic,  or  on-going  activities  which  puH 
together  appropriate  management  and/or  technical  expertise  to  direct,  assist,  guide,  or  execute  an 
assigned  task.  Steering  groups  are  typically  formed  to  provide  management  oversight,  guidance, 
advice,  or  approval  authority  for  specified  activities.  Working  groups  typically  formed  to  manage  and 
execute  a  specified  task.  Any  number  of  these  groups  may  be  formed  at  the  lead  MAJCOMs'  discretion 
to  support  their  accomplishment  of  assigned  Phase  0  responsibilities:  however,  some  groups  may  be 
directed  by  the  PMD  or  other  authority.  Two  particular  groups,  the  Concept  Action  Group  (CAG)  and  the 
Study  Advisory  Group  (SAG),  will  typically  be  formed  and  1^  by  the  lead  MAJCOM  for  Phase  0  efforts. 

(1 )  Concept  Action  Group  (CAG)  -  The  CAG  is  a  working  level  (0-6  and  below)  steering 
group,  established  and  led  by  the  lead  MAJCOM  to  manage  Phase  0  concept  studies  and  the  Cost  and 
Operational  Effectiveness  Analyses  (COEA).  The  term  "CAG"  is  typically  associated  only  with  ACAT  I 
designated  Phase  0/1  efforts.  For  ACAT  ll-IV  efforts  an  equivalent  group  may  be  formed,  but  is  typically 
called  a  "study  team."  Unless  directed  by  the  Phase  0  PMD,  the  establishement  of  the  CAG  (or  study 
team)  by  the  lead  MAJCOM  is  optional.  It  is  considered  a  best  practice,  however,  that  the  lead 
MAJCOM  seriously  consider  such  a  group  for  all  Phase  0  efforts.  The  specific  responsibilities  of  a 
particular  CAG  (or  study  team)  are  determined  by  the  lead  MAJCOM,  but  should  typically  include  the 
following; 

Manage  the  development  of  the  Phase  0  concept  studies  and  the  COEA. 

Ensure  all  Phase  0  study  objectives  are  established  and  appropriate  plans  and  schedules  are  completed 
and  maintained  to  increase  the  likelihood  that  all  study  objectives  are  met  in  a  timely  manner.  Some 
examples  of  the  CAG  ( or  study  team)  responsibilities  in  this  regard  are  to; 

Validate  all  study  objectives. 

Provide  study  planning  guidance  to  implementing  organization(s). 

Review  and  coordinate  on  implementing  organization(s)  study  plans  and  schedules,  including  the 
COEA  I  Plan. 

Ensure  Phase  0  study  plans  and  schedules  conform  to  ADM  and  PMD  direction. 

Ensure  implementing  organizations  have  and  use  approved  models  and  data  bases  for  all  studies  and 
analyses.  Some  examples  of  the  CAG  (or  study  team)  responsibilities  in  this  regard  are  to: 

Notify  AF/IN  and/or  DIA  to  develop/update  system  threat  assessment. 

Establish  approved  sources  for  needed  data  on  existing  weapon  systems. 

Establish  approved  rrKxtels  for  accomplishing  Phase  0  study  tasks. 

Identify  and  assign  data  management  responsibilities. 

Identify  all  alternative  concepts  to  be  studied  during  Phase  0.  Some  examples  of  the  CAG  (or  study 
team)  responsibilities  in  this  regard  are  to; 

Identify  any  materiel  alternatives  to  be  studied  beyond  those  directed  in  the  ADM  and  PMD. 
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Establish  the  current  cap^lity  to  which  all  materiel  altemative  concepts  will  be  compared 
against  through  the  COEA 

Recommend  all  alternatives  and  corresponding  configuration(s)  to  be  submitted  to  the  SAG  and  the 
MAJCOM/CC  for  approval  for  inclusion  in  the  COEA. 

Review  and  coordinate  on  the  results  of  the  COEA  and  the  Draft  COEA  Report  prior  to  forwarding  for 
forther  reviews  and  approvals.  Based  on  the  results  of  the  COEA,  make  recommendations  on  the 
preferred  attemative(s)  and  configurations(s)  to  be  carried  forward  for  the  Milestone  Review. 

CAG  membership  is  determined  by  the  lead  MAJCOM,  but  AFMC  representation  on  the  CAG  (or 
Study  Team)  should  minimally  include  representation  from  AFMC/XR  and  FM  and  the  PCs/ALCs.  The 
PC/ALC,  membership  should  minimally  include  at  least  one  qualified  individual  from  each  of  the 
following  technical  disciplines;  studies  and  analysis,  systems  engineering,  logistics,  test,  financial 
management,  intelligence,  and  the  laboratory.  Other  typical  organizational  participation  on  the  CAG  is 
discussed  in  AFMC  Pamphlet  173-1 ,  Section  3.  The  CAG  meets  periodically,  as  required.  Early  in 
Phase  0  the  CAG  may  meet  once  every  other  week,  or  every  month.  As  the  Phase  0  activities  mature, 
the  need  for  the  CAG  will  be  less  frequent,  arfo  they  may  meet  only  once  a  quarter,  or  after  completion 
of  specific  project  milestones.  Once  initiated,  the  CAG  will  typically  exist  until  the  Phase  I  COEA  has 
been  approved. 


(2)  Studies  Advisory  Group  (SAG)  •  The  SAG  is  a  senior-level  (0-6  and  atx>ve) 
management  oversight  group  established  and  led  by  the  lead  MAJCOM  to  ensure  the  Operating 
Command.  Implementing  Command,  and  decision  makers  continue  in  concert  througout  the  Phase  0 
concept  studies  and  the  Cost  and  Operational  Effectiveness  Analyses  (COEA).  Unless  directed  by  the 
Phase  0  PMD,  the  establishement  of  the  SAG  by  the  lead  MAJCOM  is  optional.  It  is  considered  a  best 
practice,  however,  that  the  lead  MAJCOM  seriously  consider  such  a  group  for  all  Phase  0  efforts.  The 
specific  responsibilities  of  a  particular  SAG  (or  study  team)  are  determined  by  the  lead  MAJCOM,  but 
should  typically  include  the  following; 

Direct  the  development  of  the  Phase  0  concept  studies  and  the  COEA. 

Provide  management  oversight  of  the  CAG  (or  study  team). 

Ensure  all  Phase  0  study  objectives  are  established  and  appropriate  plans  and  schedules  are  completed 
and  maintained  to  increase  the  likelihood  that  all  Phase  0  study  objectives  are  met  in  a  timely  manner. 
Some  examples  of  the  SAG  responsibilities  in  this  regard  are  to; 

Validate  arxf  approve  all  study  objectives. 

Provide  guidance  to  the  CAG  (or  study  team). 

Review  and  approve  Phase  0  study  plans  and  schedules,  including  the  COEA  I  Plan. 

Ensure  Phase  0  study  plans  and  schedules  conform  to  ADM  and  PMD  direction. 

Approve  all  alternatives,  beyond  those  directed  by  the  PMD,  to  be  studied  during  Phase  0. 

Review  and  approve  all  alternatives  and  corresponding  configurations  to  be  submitted  for  lead 
MAJCOM/CC  approval  for  inclusion  in  the  COEA.  The  SAG  and/or  the  lead  M/\JCOM/CC  can  only 
eliminate  alternatives  not  directed  by  the  ADM  or  PMD.  Recommended  alternatives  and  corresponding 
configurations  are  supplied  by  the  Implementing  Command  through  the  CAG  (or  study  team). 
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Review  and  coordinate  on  the  results  of  the  COEA  and  the  Draft  COEA  Report  prior  to  forwardmg  for 
further  reviews  and  approvals.  Based  on  the  results  of  the  COEA.  approve  CAG  (or  study  team) 
recommendations  on  the  preferred  altemative(s)  and  configurations(s)  to  be  carried  forward  tor  the 
Milestone  Review. 

SAG  membership  is  determined  by  the  lead  MAJCOM,  but  should  consist  of  senior 
representatives  from  the  operating  command,  AFMC  and  PCs/ALCs,  SAF/AQ  aixl  FM,  USAF/XOR, 
AFSAA,  AFCAA,  and  others  as  required.  The  SAG  will  typically  only  convene  at  the  request  of  the  lead 
MAJCOM  or  after  completion  of  specific  project  milestones  where  specific  approvals  may  be  required. 
Once  initiated,  the  SAG  will  typically  exist  until  the  Phase  I  COEA  has  been  approved.  The  SAG  may  be 
reestablished,  as  required,  to  review  and  approve  Phase  ll-IV  COEAs. 

8.  ENTRANCE  AND  EXIT  CRITERIA: 

a.  Entrance  Criteria: 

CofKept  Studies  Approval  -  When  the  Milestone  Decision  Authority  (MDA)  is  satisfied 
with  the  MNS  and  any  requested  Phase  0  plannir>g  intormation,  approval  is  given  to  proceed  with  Phase 
0  concept  studies.  The  MDA  will  issue  an  ADM,  and  AF/XOR  will  issue  a  PMD.  After  receiving  these 
documents  the  lead  MAJCOM  will  update  Air  Force  Phase  0  plans  as  required  to  bring  them  in  line  with 
the  guidance  provided  by  the  ADM  and  PMD. 

b.  Exit  CrKeria: 

(1)  Phase  0  Plans  Updated  and  Approved  -  After  receiving  the  PMD,  the  lead  MAJCOM 
will  ensure  Air  Force  Phase  0  plans  are  updated  as  required  to  bring  them  in  line  with  the  direction 
provided  by  the  ADM  and  PMD.  Once  final  approval  is  made  by  the  designated  approval  authority,  the 
plans  are  baselined  and  then  executed. 

(2)  Steering  and  Working  Groups  Established  -  If  the  approved  Phase  0  plans  identity 
the  need  or  desire  for  any  management  or  technical  support  groups,  charters  should  be  drawn  up  and 
approved  by  the  lead  MAJCOM  to  establish  them.  Once  established,  these  groups  should  begin  to 
execute  their  responsibilities  as  required. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Key  Inputs; 

(1 )  Acquisition  Decision  Memorandum  (ADM)  (see  A9  and  B9)  -  The  ADM  documents 
the  decisions  made  as  the  result  of  the  Milestone  Decision  Review.  The  ADM  is  signed  and  issued  by 
the  Phase  0  MDA.  For  DAB  designated  activities  (typically  ACAT  ID  efforts),  the  MDA  will  be  the 
USD(A)  (see  A9).  For  non-DAB  designated  activities  (typically  ACAT  IC  and  ACAT  ll-IV  efforts),  the 
MDA  will  be  the  Service  Acquisition  Exectutive  (SAE)  or  whomever  the  SAE  delegates  this  authority  to 
(see  B9).  The  Phase  0  ADM  will  accomplish  the  following  for  Phase  0; 

Define  the  minimum  set  of  alternative  concepts  to  be  examined. 

Identify  the  lead  organization(s)  for  the  study  efforts. 

Establish  any  exit  criteria  information  or  analyses  that  must  be  presented  at  MS  I. 

Identify  the  dollar  amount  and  source  of  funding  for  the  study  efforts  to  be  conducted. 
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(2)  Program  Management  Directive  (PMD)  (see  BIO)-  The  PMD  is  the  official  Air  Force 
document  used  to  direct  acquisition  or  modification  responstoilities  to  appropriate  Air  Force  MAJCOMs 
for  the  development,  acquisition,  or  modification  of  a  specific  weapon,  subsystem,  or  piece  of 
equipment.  The  Phase  0  PMD  is  issued  by  USAF/XOR  and  wilt  accomplish  the  following  for  Phase  0: 

Designate  the  lead  MAJCOM. 

Identify  and  direct  all  partic^ating  organizations. 

Identify  the  MAJCOM  responsible  for  establishing  the  CAG  (if  required)  and  for  leading  the  concept 
studies. 

Identify  funding  sources  and  approved  study  alternatives. 

Briefly  address  the  purpose,  study  requirements,  required  documentation,  and  schedule  considerations 
for  the  Milestone  I  (MS  I)  decision. 

Establish  Air  Staff,  SAF,  Joint  Staff,  and  OSD  review  and  coordination  procedures  for  MS  I  decision. 

The  Phase  0  PMD  will  incorporate  and  expand  on  the  direction  provided  by  the  ADM.  It  is  required  by 
the  lead  MAJCOM  and  other  participating  organizations  to  identify  the  funding  source  and  amount,  and 
justify  the  further  expenditure  of  resources  for  the  planned  Phase  0  activities. 

(3)  Draft  Phase  0  Plans  (see  C14)  -  These  are  the  draft  plans  developed  by  the  lead 
MAJCOM  prior  to  the  Milestone  Decision.  These  plans  provide  an  integrated  Air  Force  Phase  0  planning 
position  regarding  the  following: 

Phase  0  purpose,  objectives,  constraints,  and  assumptions. 

The  proposed  strategy  and  organization  for  accomplishing  Phase  0. 

Identification  of  the  tasks  and  estimates  of  the  required  schedule  and  resources  needed  to  accomplish 
Phase  0. 

The  lead  MAJCOM  must  ensure  that  this  information,  and  all  organizational  plans  based  upon  it,  are 
consistent  with  the  Phase  0  ADM  and  PMD  direction. 

(4)  DIA  and  USAF/IN  Threat  Support  (see  A10  and  B1 1)  -  Intelligence  support  will  be 
required  throughout  the  execution  of  the  Phase  0  activities,  including  the  support  to  steering  and  working 
groups  like  the  CAG  and  the  SAG.  The  lead  MAXOM  must  ensure  the  appropriate  support  is  requested 
from,  and  provided  by,  the  intellegence  communities. 

b.  Key  Outputs: 

(1 )  Approved  Phase  0  Plans  -  After  the  lead  MAJCOM  and  all  of  the  participating 
organizations  have  accounted  for  ADM  and  PMD  direction  and  have  updated  and  coordinated  Phase  0 
plans,  the  lead  MAJCOM  will  fonward  the  documented  Air  Force  planning  position  to  the  designated 
approval  authority  for  approval.  Once  approved,  these  plans  become  the  baseline  for  Air  Force 
management  and  control  of  the  Phase  0  activities.  Typically  the  approval  authority  for  these  plans  will 
reside  with  the  SAG  or  the  lead  MAJCOM/CC.  For  DAB  designated  programs,  however,  approval 
authority  for  all  or  some  of  the  plans  may  reside  with  USAF/XO,  the  CSAF,  the  SAE,  the  PEG  (if  one  has 
been  identified),  or  OASD(PA&E).  The  required  review  and  approval  procedures  should  be  identified  by 
the  Phase  0  PMD. 
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(2)  Steering  and  Working  Group  Charters  -  Each  leering  or  working  group  kxmed  by 
the  lead  MAJCOM  should  have  a  charter  approved  by  the  lead  MAXOM  which  ideraifies  group 
functions,  responsibilities,  organization,  membership,  and  ro'es  and  responsibililies  for  the  membership 
within  the  group.  This  charter  should  have  ties  back  to  the  PMD  and  provide  all  of  the  necessary 
direction  the  group  needs  to  operate.  The  charter  must  be  defined  in  erxxigh  detaU  to  distinguish  the 
responsibilities  of  the  steering  or  worksig  group  from  the  responsibilities  of  the  other  Phase  0 
participants. 

10.  KEY  REFERENCES: 

DoO  Directive  5000.1 , 23  Feb  91 .  ’Defense  Acquisition,’  provides  overall  DoD  defense  acquisition 
policies. 

DoD  Instmction  5000.2,  23  Feb  91 .  ’Defense  Acquisition  Management  Policies  and  Procedures,’  Section 
E,  paragraph  2,  provides  DoD  policies  on  program  plans. 

AF  Policy  Letter  91 M-001 .  20  Jun  91 .  ’Early  Industry  Involvement  in  Acquisition  Planning.*  establishes 
SAF  policies  regarding  early  Industry  involvement  in  acquisition  planning. 

AFMC  Pamphlet  173-1 , 30  Dec  92,  ’AFMC  Cost  and  O^ational  Effectiveness  Analysis  (COEA)  Guide,’ 
Section  3.  discusses  COEA  organizational  responsibilities.  irKluding  the  CAG  and  SAG. 

11.  PLANNING  GUIDANCE: 

a.  DURATION; 

(1 )  Updating  the  Phase  0  Plans  •  Assuming  the  ADM  and  PMD  contain  no  suprises,  the 
lead  MAJCOM  should  allot  at  least  2-4  weeks  to  corr^lete  and  obtain  final  coordination  an'‘  approval  of 
the  Phase  0  plans.  If  the  ADM  and  the  PMD  cause  significant  changes  to  the  Air  Force  p  >iing 
position,  or  add  unexpected  requirements  or  participants,  considerably  more  time  will  typically  be 
required  to  account  for  these  changes.  If  the  lead  MAJCOM  is  anticipating  such  changes,  for  whatever 
reason,  an  additional  2-4  months  is  likely  a  better  planning  estimate  for  final  Phase  0  planning  approval. 

(2)  Establishing  Steering  and  Working  Groups  -  Developing  the  Charter  for  each  of  the 
steering  or  working  groups  can  typically  be  accomplished  in  less  than  1  week.  Formal  coordination  and 
approval  of  the  Charter  could  take  several  weeks  to  several  months,  depending  on  the  number  of 
organizations  involved.  In  most  cases,  these  groups  should  begin  to  execute  their  responsbHities  as 
soon  as  required.  The  formal  approval  of  the  Charter  shouldn't  necessarily  delay  their  start. 

b.  CONSTRAINTS: 

(1 )  PMD  Direction  -  The  direction  provided  by  the  PMD  must  be  satisfied  by  the  Phase  0 

plans. 


c.  RESOURCES: 

(1 )  Updating  the  Phase  0  Plans  -  To  update  the  Phase  0  plans,  the  lead  MAJCOM  must 
engage  the  support  of  all  of  the  participating  organizations  identified  in  the  PMD.  For  Phase  0  efforts, 
this  will  typically  include  personnel  from  USAF/XOR,  SAF/AQ,  AFMC  PCs/ALCs,  the  Office  of 
Aerospace  Studies  (OAS),  and  other  MAJCOM  organizations.  If  there  are  Joint  Service  or  international 
implications,  then  personnel  from  those  organizations  must  also  be  involved. 

(2)  Establishing  Steering  ard  Working  Groups  -  The  PC/ALC  should  dedicate  at  least 
one  resource  to  supporting  the  lead  MAJCGMs  planning  and  establishment  of  any  steering  or  working 
groups  they  identify,  like  the  CAG  and  the  SAG.  This  support  will  help  ensure  that  AFMC  interests  in  the 
group  are  adequately  addressed. 
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(3)  Funding  -  Sufficieni  fundhig  should  be  made  available  to  aHow  necessary  and 
appropriate  trav^  for  coNectmg  and  coordinating  planning  inputs  from/wilh  participatirtg  orgar^ations 
and  establisNng  the  CAG  ind  SAG. 

cL  LESSONS  LEARNED: 

(1 )  Updating  Phase  0  Plans  ■  None  Identified. 

(2)  Steering  and  Working  Groups 

(a)  CAG  (or  Study  Team)  Membership  -  All  PC/ALC  functional  stakeholders 
should  be  involved  early  as  memfc^  of  the  CAG  because  their  technical  expertise  is  necessary  for 
solving  typical  CAG  concerns. 

e.  BEST  PRACTICES: 

(1 )  Updating  Phase  0  Plans  •  None  Identified. 

(2)  Steering  and  Working  Groups: 

(a)  CAG  (or  Study  Team)  Involvement  in  Program  Development  -  The  CAG 
should  focus  its  efforts  entirely  on  the  concept  studies  arxf  COEA  analyses,  and  their  application  to 
requirements  definition.  The  CAG  should  not  attempt  to  guide  program  development  or  dictate 
acquisition  strategies  or  schedules. 

(b)  Establishing  a  CAG  (or  Study  Team)  ora  SAG  -  It  is  important  that  the 
PC/ALC  doesm  attempt  to  force  the  formation  of  the  CAG  or  SAG.  It  is  the  lead  MAJCOM's 
responsliility  to  determine  the  need  for  these  groups  and  establish  them  if  needed. 

f.  TRAPS: 

(1 )  Updating  Phase  0  Plans: 

(a)  PMD  Direction  -  The  direction  provided  by  the  PMD  should  not  be  left  open 
to  interpretation.  If  you  have  any  question  regarding  the  irNent  of  any  information  provided  by  the  PMD, 
get  it  clairified  before  acting  upon  it. 

(2)  Steering  and  Working  Groups. 


12.  IMPLEMENTATION  TOOLS:  None  Identified. 
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1.  ELEIIEMT:  C1 7.  TBS  1. 2.3.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Review  and  Approve  COEA  (Cost  and  Operational  Effectiveness  Analysis)  I  Plan 

3.  ELEMENT  OWNER(S):  Lead  MAJCOM  assigned  by  the  program  management  directive  (PMD) 

4.  ELEMENT  STAKEHOLOER(S):  SAF/AQ,  HQ  USAF/XOM,  Operating  MAJCOM,  AFMC,  Operating 
Test  and  Evaluation  Agency.  OASD(PA&E),  concept  action  group  (CAG),  and  the  Implementing 
Command's  Requirements  and  Fnancial  management  orgartizations. 

5.  REQUIREMENT:  AF  Regulation  800-1,  ‘Air  Force  Acquisition  System,*  paragraph  S.c,  identifies  the 
acquisition  management  responsibilities  of  Air  Force  acquisition  managers. 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose:  The  COEA  plan  is  reviewed  by  the  CAG.  SAF/AQ,  HQ  USAF/XOM.and 
OASD(PA&E).  Their  job  is  to  ensure  focused,  sustained  progress  in  developing  a  useful  analysis  to 
support  program  decisions  by  the  Defense  Acquisition  Board  (DAB)  or  the  Acquisition  Executive. 

b.  Objective:  The  coordination  process  offers  a  unique  opportunity  to  improve  the  quality  and 
develop  wide  support  for  the  COEA,  as  well  as  establishing  the  agreed-to  Phase  0  methodology  tor 
accomplishing  the  comparative  analysis  (BLK-048). 

7.  DESCRIPTION:  The  plan  should  be  coordinated  with  the  Acquisition  Command's  Directorates  tor 
Requirements  and  Financial  Management,  SAF/AQ.  and  for  ACAT  ID  programs,  be  reviewed  with 
OASD(PA&E).  This  will  help  erasure  that  all  logical,  viable  alternatives  get  a  fair  assessment  and  that 
parochialism  is  avoided.  The  process  of  writing  the  plan,(BLK  D23).  and  reviewing  the  plan,  (BLK  Cl 7), 
is  an  iterative  one  and  can  cycle  back  and  forth  until  approval  is  reached.  The  reviews  will  ensure  that 
parties  agree  on  each  organization's  responsibilities,  the  acquisition  issues,  alternatives  to  be  studied, 
and  the  analysis  methodology  and  assumptions. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  establishment  of  the  CAG  or  study  group,  (BLK  C16)  and  the  completion  of 
the  COEA  I  plan,  (BLK  023). 

b.  Exit:  The  approved  draft  COEA  I  plan. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1 )  Establishing  the  CAG  or  study  group,  (BLK  Cl  6). 

(2)  Writing  the  COEA  I  Plan.  (BLK  D23). 

(3)  Updating  the  COEA  I  Plan,  (BLK  D37). 

b.  Outputs: 

(1)  Conducting  COEA  Comparative  Analysis.  (BLK  D48). 

(2)  Selecting  COEA  I  Concepts.  (BLK  C21). 
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ia  KEY  REFERENCES: 

a.  AR  10-601.  Mission  Needs  and  Operational  Requiremenis  Guidance  and  Prooedures.  16  Feb 
93. 

b.  AFP0 10-6,  Mission  Needs  and  Operational  Requirements,  19  Jan  93. 

c.  DOO  5000.2-M,  Defense  Acquisition  ManagemerY  Documentation  and  Reports,  Feb  91 . 

d.  AFMCP 173-1 ,  AFMC  COEA  Guide,  30  Dec  92,  paragraph  2.2.6,  Guide  to  the  Review 

Process. 

11.  MPLEMENTATION  TOOLS:  AFMCP  173-1.  AFMC  COEA  Guide,  30  Dec.  92.  paragraph  2.2.6, 
guide  to  the  review  process. 

12.  PLANNMQ  GUIDANCE: 

a.  DURATION:  Iterative. 

b.  CONSTRAINTS:  Norw  Identified. 

c.  RESOURCES:  None  Identified. 

d.  LESSONS  LEARNED: 

(1)  Early  coordination  is  crucial  to  avoid  disconnects  and  revision  late  in  the  COEA 
development  process  or  near  the  Milestone  i/IV  scheduled  decision. 

(2)  It  is  common  for  the  review  and  coordination  to  be  done  in  an  ad  hoc  and  informal 
manner  by  the  stu^  group.  A  formal  process  needs  to  be  lolowed  in  order  to  get  a  better  product. 

(3)  COEA  contractors  should  not  review  their  own  plans. 

e.  BEST  PRACTICES: 

(1 )  An  excellent  reference  on  the  review  process  can  be  found  in  AFMCP  173-1, 
paragraph  2.26  ’Review  Process.’ 

(2)  OASD(PA&E)  should  be  contacted  during  the  review.  This  will  allow  for  their 
concurrence  on  the  alternatives  analyzed.  If  not  done,  could  cause  major  delays  later  on. 

f.  TRAPS:  PA&E  has  been  known  to  try  to  add  alternatives  or  change  scenarios  late  in  the 
analysis  process.  Try  to  get  PA&E's  written  concurrence  or  coordination  on  the  COEA  plan. 


% 


.♦) 


•  • 


D-226 


Novn 


1.  ELEMENT:  CIS.  TBS  1. 2.2.1  IFC  93-3 

2.  ELEMENT  TITLE:  Develop  Draft  ORD I 

3.  ELEMENT  OWNER(S):  Operating  MAJCOM 

4.  ELEIMCNT  STAKEHOLOER(S):  Air  Force  Materiel  Command  (AFMC),  Product  Center  (ASC),  and 
Industry. 

5.  REQUIREMENT: 

a.  DOD  Directive  5000.1 ,  Defense  Acquisition,  23  Feb  91 ,  Part  2,  Paragraph  B.6,  states  how  the 
ORD  interacts  with  the  requirements  generation  and  acquisition  management  system  through  Phases 
and  Milestone  decision  points. 

b.  DOD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures.  23  Feb  91 . 
Part  4,  Section  B.  states  the  basis  for  the  determination,  evolution,  documentation,  and  validation  of 
mission  needs  and  system  performance  requirements. 

6.  PURPOSE/OBJECTIVES. 

a.  Purpose:  Identify  how  a  system  will  operate,  deploy,  empby,  and  be  supported 

b.  Objective;  During  Conc^t  Exploration  and  Definition,  it  provides  inKial  requirements 
guidance  for  Implementing  and  Participating  Commands  and  agencies  to  use  in  assessing  alternative 
design  concepts. 

7.  DESCRIPTION: 

a.  The  lead  operating  Major  Command  (MAJCOM)  will  prepare  the  initial  ORD  I  describing  pertinent 
quantitative  and  qualitative  performance,  operation,  and  support  parameters,  characteristics,  and 
requirements  for  each  specific  candidate  weapon  system.  While  developing  this  ORD,  the  operating 
MAJCOM  may  request  AFMC  assistance  in  evaluating  potential  materiel  alternatives  and  to  identify 
opportunities  for  cost,  schedule,  performance,  and  support  tradeoffs.  The  Product  Centers  will  provide 
expertise  in  evaluating  altemative  technical  solutions  to  meet  requirements,  guiding  laboratory  efforts 
relating  to  emerging  technologies,  helping  in  planning  to  prioritize  exploratory  and  advance  development 
reviews  and  assisting  in  evaluating  executsbility  of  programs.  Product  Centers,  industry,  or  a  support 
contractor  can  conduct  trade  studies  or  other  analyses-specifically  the  Cost  and  Operational 
Effectiveness  Artalysis  (COEA)~to  provide  quantitative  data  to  assist  in  establishing  or  evaluating 
potential  requirements. 

b.  The  A^isition  Decision  Memorandum  (ADM)  from  the  Milestone  0  decision  directs  studies, 
designates  military  department  to  conduct  concept  studies,  and  identifies  a  source  of  funding.  The 
results  from  the  corx:^  studies  provide  the  user  with  necessary  data  for  translating  the  broadly  stated 
needs  (from  the  Mission  Need  Statement  (MNS))  into  operational  perfonnance  parameters  and  threshold 
(minimum  acceptable)  operational  requirements  for  the  most  promising  system  concept(s).  During 
Coricept  Exploration  and  Definition,  the  number  of  parameters  and  threshold  values  should  be  kept  to  a 
minimum.  Objectives  may  be  established.  The  purpose  is  to  facilitate  future  design  tradeoffs.  The  ORD 
will  continue  to  evolve  after  Milestone  I  or  program  approval.  This  document  is  the  bridge  connecting 
the  MNS  to  the  APB  and  the  specifications  for  the  system  corx:ept(s).  A  specific  format  and  a  formal  list 
of  required  coordination  agencies  are  annotated  in  DOD  5000.2-M,  Part  3,  Attachment  1 .  and  AF1 10- 
610,  Attachment  6,  respectively. 

c.  At  the  Department  of  Defense  (DOD)  level,  the  ORD  irx:ludes  an  operational  capability 
description;  existing  systems  shortcomfogs  and  threats;  capabilities  required;  support  concept;  including 
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draft  maintenance  concept,  infrastructure  support  and  intetx>perat3^;  force  structure;  and  operational 
need  dates.  The  ORO  will  establish  objectives  and  threshold  requirements  for  those  performance 
capabiMy  parameters  necessary  to  characterize  the  proposed  systemfs). 

d.  The  Air  Force  has  expanded  the  ORD/RCM  documentation  requirements  in  many  areas.  The 
most  significant  is  a  mandatory  attachment  called  the  Requirements  Correlation  Matrix  (RCM).  The 
RCM  provides  the  basis  tor  operational  needs  and  requirements  to  be  included  in  the  integrated  Program 
Summary  (IPS).  System  Maturity  Matrix  (SMM),  Test  and  Evaluation  Master  Plan  (TEMP),  and 
Acquisition  Program  Baseline  (APB).  The  RCM  is  not  a  stand-alone  document,  but  a  quick  reference 
listing. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrarce;  Program  Management  Directive  (PMO)  issued. 

b.  Exit:  Draft  ORD/RCM  ready  for  Air  Force  coordination  and  operating  MAJCOM  approval. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  Concept  of  Operations  (C2) 

(2)  Mission  Needs  Statement  (C1 2) 

(3)  Cost  arKl  Operational  Effectiveness  Analysis  (COEA)  Results  (C23) 

(4)  COEA  Comparative  Analysis  (D48) 

(5)  Trade  Studies  results  from  concept  studies 

(6)  MAJCOM  Preferred  Alternative(s)  Selection  (C25) 

b.  Output:  Draft  ORD/RCM  tor  Air  Force  coordination  and  lead  MAJCOM/CC  approval  (C26). 

10.  KEY  REFERENCES: 

a.  AF1 10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and  Procedures,  16  Feb  93, 
paragraphs  1 .5  and  1 .6,  and  Attachments  6  and  7.  This  regulation  defines  what  ORD/RCM  are  and  the 
procedures  to  generate  the  documents. 

b.  DOD  instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb  91 , 
Part  4,  Section  B  states,  the  basis  for  the  determination,  evolution,  documentation,  and  validation  of 
mission  needs  arxf  system  pertormarx:e  requirements. 

c.  [X)D  5000.2-M,  Defense  Acquisition  Management  Documentation  and  Reports,  Feb  91 ,  Part  3. 
This  directive  contains  the  ORD  format  and  content. 

11.  IMPLEMENTATION  TOOLS: 

a.  AFMCP  173-1,  Draff  AFMC  Cost  &  Operational  Effectiveness  Analysis  (COEA)  Handbook,  Aug  92. 
This  handbook  defines  the  interrelationship  of  the  ORD  with  the  COEA. 

b.  Lessons  learned  are  documented  in  the  Automated  Lessons  Learned  Capture  and  Retrieval  System 
(ALLCARS)  maintained  by  ASC/CYM  at  Wright  Patterson  AFB  OH  45433-5000,  DSN  785-3454. 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  To  draft  an  ORD  for  coordination  may  require  6  to  1 B  months  to  complete  for  a 
Milestone  I  decision.  Such  factors  as  complexity,  level  of  coordination  and  approval,  etc.,  determine  the 
timelines.  Normal  suspense  for  completing  a  draft  ORD  is  180  days  from  time  of  tasking  (after  issuing 
the  PMD).  This  is  predicated  on  pending  Milestones.  Reviews.  Summits,  etc.  If  the  ORD  is  dependent 
on  accor^ishirrg  a  COEA  (as  It  should  be)  a  longer  time  period  will  be  required. 

b.  CONSTRAINTS:  The  lead  MAJCOM  cannot  con^ete  the  first  ORD  until  the  lead  MAJCOM 
COEA  I  report  is  available.  A  draft  ORD  may  be  written  early  in  Concept  Exploration  phase  to  help  focus 
or  identify  required  trade  studies. 

c.  RESOURCES:  The  operating  MAJCOM  should  assign  an  action  office  to  ensure  all  sections 
are  incorporated  into  the  ORD.  The  resources  and  man-hours  are  two  actbn  officers  on  a  part-time 
basis  for  6- 18  months  deperxjing  on  the  complexity  of  the  project. 

d.  LESSONS  LEARNED: 

(1)  Operatk)n.a'  requirements  must  describe  the  overall  mission,  the  preferred 
anemative(s),  and  anticipated  operational  scenario  downstream.  This  will  promote  the  necessary 
program  and  integrated  logistics  support  planning  functions.  Failure  to  do  so  jeopardizes  the  balame 
between  affordability,  system  performance,  reliability  and  supportability  for  initial  operational  capability 
(USNLL  #10069). 

(2)  The  operating  MAJCOM  rrujst  define  a  minimum  set  of  operational  requirements, 
capabilities  and  performance  parameters  in  the  ORD  by  Milestone  1 .  Without  a  clear  understanding  of 
these  requirements  and  any  associated  objectives,  contractor  proposal  for  the  Demonstration  and 
Validation  RFP  may  make  an  apples-to-apples  comparison  difficult  and  increase  the  complexity  of 
source  selection. 

e.  BEST  PRACTICES: 

(1)  The  requirements  in  the  ORD/RCM  become  the  basis  for  operational  performance 
criteria  and  testing.  When  establishing  a  requirement,  make  sure  it  can  be  tested  given  the  limits  of  the 
test  equipment  and  technology.  It  will  cause  perturbations  later  in  the  program  if  operational  testers 
cannot  find  a  way  to  verify  ORD/RCM  requirements  due  to  test/measurement  technology  limitations. 

(2)  The  operating  MAJCOM  needs  to  minimize  specific  key  parameters  for  the  total 
system  performance  whenever  possible  to  allow  maximum  flexibility  within  subsystems  as  the  system 
evolves.  Performance  standards  specified  as  minimum  acceptable  should  be  threshold  values.  The 
ORD  objectives  provide  an  opportunity  for  the  user  to  identify  operationally  significant  performarx;e 
above  the  thresholds.  In  later  program  phases,  the  ORD  may  reflect  different  thresholds  as 
understanding  of  the  system  matures.  This  is  called  evolutionary  requirements  definition  as  described  in 
DODI  5000.2,  Section  4-B. 

f.  TRAPS:  Reference  above  "Best  Practices  and  Lessons  Learned." 


•  • 


D-229 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


Nav«3 


1.  ELEMENT:  C21.  TBS  1. 2.3.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  S^ect  COEA I  Concepts 

3.  ELEMENT  OWNER(S):  Operating  Commands 

4.  ELEMENT  ST AKEHOLDER(S):  Product  and  Logistic  Centers. 

5.  REQUIREMENT:  DODD  5000.1 .  Part  1 .  paragraph  4b;  DODi  5000.2,  Part  4,  Section  E 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose;  For  the  Corrcept  Action  Group  (CAG)  or  some  other  assembly  to  decide  which 
system  aHematives  are  studied  in  support  of  the  Cost  and  Operational  Effectiveness  Analysis  (COEA). 

b.  Objectives;  By  the  process  of  elimination  and  by  direction  in  the  Milestone  0  Program 
Management  Directive  (PMD),  a  list  of  feasible  alternatives  will  be  determined  for  use  in  the  COEA 
activities. 

7.  DESCRIPTION:  The  CAG  or  equivalent  reviews  all  of  the  system  solutions  studied  during  the 
Systems  Requirements  Analysis  (D37)  and  presented  during  the  Alternative  Systems  Review  (D45),  and 
selects  those  deemed  reasonable  and  appropriate  for  further  study  in  the  CO^  process  (D48)  and 
drafting  the  Operational  Requirements  Document  (ORD  -  C19).  The  CAG  or  equivalent  must  also 
include  for  further  study  a  wide  range  of  feasible  and  significant  alternatives  that  might  satisfy  the 
mission  need  ~  such  as  modifying  existing  systems,  systems  under  development,  systems  used  by  other 
Services,  or  systems  being  used  or  develop^  by  U  S.  allies.  Each  ahemative  description  should  include 
the  system  capabilities  against  proj^ed  threats  with  varying  scenarios,  its  constrairrts,  and  systems  risks 
and  uncertainties  to  determine  availability.  Alternatives  are  not  just  limited  to  hardware  and  software 
used  to  fuK ill  the  need  -  variations  on  doctrine  and  tactics  should  again  be  considered  as  was  done  prior 
to  the  writing  of  the  Mission  Need  Statement  (C7).  If  this  review  did  not  consider  all  of  the  alternatives 
that  might  satisfy  the  mission  need,  then  those  alternatives  need  to  be  included  in  the  Systems 
Requirements  Analysis  (D37)  concept  update. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Alternative  Systems  Review  (D45)  corr^leted. 

b.  Exit;  A  list  of  selected  alternatives  under  consideration  to  fulfill  the  user's  need  for  use  in  the 
Program  Alternatives  Analysis  (PAA  -  D46)  and  COEA  Comparative  Analysis  {D48). 

9.  KEY  INPUTS/OUTPUTS: 

a.  Input;  Concept  exploration  study  and  study  team  matrix  of  alternative  solutions  (D45). 

b.  Output;  A  list  of  selected  alternatives  under  consideration  to  fulfill  the  user's  need  for  use  in 
the  PAA  {D46)  and  COEA  (D48). 

10.  KEY  REFERENCES:  DODI  5000.2,  Part  4,  Section  E;  DOD  5000.2-M,  Part  8;  AF1 0-601, 
Attachment  5;  AFMC  Cost  and  Operational  Effectiveness  Handbook  (AFMCP-173-1);  OASD/PA&E  Cost 
and  Operational  Effectiveness  Analysis  Guidelines  (DOD  5000.1-G). 

11.  IMPLEMENTATION  TOOLS:  None  identified. 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  Depending  on  the  size  of  the  project,  this  process  of  selecting  the  alternatives 
studied  in  the  COEA  may  take  an  afternoon  or  as  many  as  several  weeks  to  several  months  to 
accomplish.  Air  Mobility  Command  (AMC)  utilizes  a  series  of  CAG  working  group  nieelings  to 
recommerxj  the  selections,  with  the  CAG  making  the  final  selections  as  a  committee.  Air  Combat 
Command  (ACC)  utilizes  action  officers  to  do  the  research  and  make  the  selections,  which  would  take 
less  time  than  a  committee  decision. 

b.  CONSTRAINTS:  None  identified. 

c.  RESOURCES:  AMC  CAGs  consist  of  colonels  with  working  groups  of  lower  ranking  officers  and 
civilians.  ACC  utilizes  small  teams  of  action  officers  (or  maybe  just  one  action  officer  on  a  small 
project)  to  act  as  the  CAG. 

d.  LESSONS  LEARNED:  There  are  usually  more  alternatives  that  should  be  explored/analyzed 
than  what  is  initially  considered.  Senior  leaders  will  frequently  add  to  the  list  during  the  COEA  process. 

e.  BEST  PRACTICES:  The  Systems  Requirements  Analysis  .should  have  already  included  the 
"wide  range  of  feasible  and  significant  alternatives  that  might  satisfy  the  mission  need"  as  described  in 
paragraph  7  above.  This  set  of  alternatives  may  be  contained  in  the  Program  Management  Directive 
(PMD)  at  Milestone  0  (BIO),  included  during  the  CAG's  formulation  of  the  COEA  plan  (element  C16),  or 
identified  during  the  COEA  plan  review  (C17).  Should  any  viable  alternatives  not  be  addressed  in  the 
Alternative  Systems  Review,  the  project  will  suffer  delays  while  those  overlooked  alternatives  are 
studied.  Ckx)rdinate  the  COEA  activities  with  OASD/PA&E  to  ensure  a  favorable  review  of  the  results 
(C29). 

f.  TRAPS:  None  identified  . 
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1.  ELEMENT:  C22.  TBS  1.2.3.8.1  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  Cost  Estimate  and  Update  Budget  Request  (CC#  93-0117] 

3.  ELEMENT  OWNER:  Operating  Command 

4.  ELEMENT  STAKEHOLOER(S):  SAF/AQ/FMB.  AF/XOR.  and  Project  Manager. 

5.  REQUIREMENT:  DoO  Directive  7045.14,  The  Planning,  Programming,  and  Budget  System  (PPBS), 
22  May  84,  and  Air  Force  Instoiction  10-601,  paragraph  1.2.3. 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose:  The  purpose  of  this  activity  is  to  obtain  Operating  Command  approval  for  the 
project  office  estimate  of  the  anticipated  preferred  program  alternative. 

b.  Objective:  Get  the  program  office  cost  estimate  included  into  the  Air  Force  budget  or 
approved  for  use  to  support  other  exercises,  as  appropriate. 

7.  DESCRIPTION:  At  this  point  in  the  project,  the  Operating  Command  should  have  selected  the 
program  alternative  (C25)  that  will  be  proposed  for  the  Milestone  I  decision  review.  Therefore,  if  there  is 
an  Air  Force  Program  Objective  Memorandum  (POM)  exercise  planned  (B13),  and  program  funding  will 
be  required  in  the  POM  years,  the  Program  Cost  Estimate  (D47)  should  be  uj^ated  to  quantify  and 
document  the  financial  requirements  for  the  preferred  program  for  incorporation  into  the  Operating 
Command  POM  submission. 

a.  There  are  two  activities  in  this  element.  First,  the  project  office  estimate  of  the  program 
should  be  completed  and  provided  to  the  Operating  Command  for  review  and  approval.  This  should  be 
accomplished  prior  to  the  use  of  the  estimate  for  budget  submissions,  or  other  planning  activities.  The 
review  should  be  accomplished  to  assure  that  the  estimate  is  representative  of  the  program  that  will  be 
recommended  to  address  the  Command's  operational  deficiencies.  The  magnitude  and  extent  of  the 
review  could  be  expected  to  vary,  based  on  the  ACAT  level  of  the  program,  the  magnitude  of  the 
program  costs,  aixf  the  general  level  of  interest  in  the  program.  The  project  OPR  in  the  Operatir^ 
Command  should  be  responsible  for  coordinating  the  specific  review  requirements.  If  the  (Operating 
Command  has  established  a  Concept  Action  Group  (CAG)  to  direct  and  oversee  the  project  Phase  0 
study  activities  (Cl  6),  the  CAG  should  perform  this  function,  if  the  CAG  has  been  given  the  authority  to 
review/approve  the  project  activities.  For  the  purpose  of  this  discussion,  it  is  assumed  that  a  CAG  has 
been  established. 

b.  Secondly,  when  there  is  an  opportunity  to  get  the  approved  program  estimate  incorporated 
into  the  Operating  Command  POM  submission  to  Air  Staff  (B13),  this  should  be  accomplished  to  get  the 
project  fundirig  requirements  approved.  To  achieve  this,  the  CAG  should  work  with  the  Project  Office  to 
ensure  that  a  POM  input  is  developed  which  meets  the  current  CAG  requirements  and  can  be  supported 
in  the  Operating  Command  POM  review  process.  (Note:  Since  a  delay  may  occur  between  the  estimate 
completion  (and  approval)  and  the  POM  submission,  fact  of  life  changes  may  require  the  project  office  to 
develop  and  submit  program  and  estimate  variations  in  the  POM).  When  the  POM  inputs  are  received 
from  the  Product  Centers,  the  CAG  should  be  prepared  to  address  program  issues,  and  support  the 
project  in  the  review  process.  Further,  a  CAG  representative  should  serve  as  the  interface  with  the 
Project  Office  when  »fditional  information  or  analysis  excursions  are  required. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  ENTRANCE:  The  need  for  the  effort  described  above  at  this  phase  of  the  project  should  be 
primarily  dependent  on  the  anticipated  ability  to  interject  the  estimated  project  costs  into  the  Air  Force 
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POM  and  to  establish  a  preliminary  financial  position  for  the  anticipated  program.  The  CAG  may  also 
task  the  Project  Office  to  generate  program  estimates  to  support  other  planning  activities. 

b.  Exit;  Approval  of  the  project  office  estimate  by  the  Operating  Command,  and  if  possible, 
inclusion  of  the  estimate  into  the  Air  Force  POM  process  (B13). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  INPUTS:  The  primary  input  for  the  estimate  review  is  the  Project  Office  Program  Cost 
Estimate  (D47).  Additionally,  the  results  of  the  Preferred  Altemativefs)  Selection  (C25)  should  be  useful. 
The  inputs  to  the  POM  include  the  fiscal  and  resource  constraints  placed  on  the  Operating  Command  in 
the  MAJCOM  specific  BPPBS  baseline  (normally  received  in  the  spring  of  the  odd-numbered  years),  and 
the  POM  Preparation  Instructions  (normally  received  from  AF/PE  in  the  summei ;. 

b.  OUTPUTS;  An  approved  project  estimate  for  planning  purposes  arxl/or  Operating  Command 
POM  submission  to  HQ  USAF  (B13). 

10.  KEY  REFERENCES:  The  references  below  provide  more  specific  implementation  guidance. 

a.  AFP  172-4,  The  Air  Force  Budget  Process,  Oct  87  -  Describes  the  Air  Force  budget 

process. 

b.  DoDI  7045.7,  Implementation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 

23  May  84  -  Describes  the  budget  process  within  the  Department  of  Defense. 

11.  IMPLEMENTATION  TOOLS:  The  PPBS  Primer,"  7th  Edition,  May  93.  This  document,  is 
published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and  provides  a 
valuable  description  of  the  current  BPPBS  process.  This  is  one  of  the  few  documents  that  describes  the 
currerrt  process,  and  it  does  so  in  detail.  Further,  it  defines  the  activity  schedule  for  the  development  of 
the  FYsis  POM.  However,  there  is  not  a  great  deal  of  information  on  POM  preparation  at  the  field  level. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  time  required  for  the  CAG  review  of  the  estimate  can  be  expected  to  be 
related  directly  to  the  level  of  communication  between  the  CAG  and  the  project  office,  the  level  of 
program  definition,  the  approval  of  previous  Project  Office  estimates,  and  the  quality  of  the  project  office 
estimate  and  the  estimate  documentation.  If  the  Project  Office  efforts  have  been  well  coordinated  with 
the  CAG.  the  review  may  be  accomplished  with  a  briefing  on  the  estimate,  or  providing  the  analysis 
documentation  to  the  CAG.  However,  if  issues  exist,  the  CAG  review  may  be  performed  over  the  period 
of  weeks,  or  longer,  if  the  Prqect  Office  is  tasked  to  perform  further  analysis.  In  the  case  of  the  POM, 
the  Operating  Command  activities  begin  in  the  spring  with  the  receipt  of  the  MAJCOM-specific  resource 
baseline,  and  end  with  the  submission  of  the  POM  to  HQ  USAF  in  August-September. 

b.  CONSTRAINTS:  The  Project  Office  cost  estimate  wilt  probably  need  to  be  performed  at  a 
very  high  level  (not  detailed)  due  to  lack  of  program  definition.’  Because  of  the  top  level  approach,  the 
estimating  methods  may  not  always  be  sensitive  to  estimating  excursions  required  by  the  CAG. 
Additionally,  the  constraints  inherent  in  the  respective  POM  resource  baseline  may  limit  the  Operating 
Commands  ability  to  support  the  desired  program. 

c.  RESOURCES:  The  composition  of  the  CAG  can  be  expected  to  relate  directly  to  the  level  of 
interest  in  the  project,  projected  costs,  and  complexity.  A  sampling  of  projects  indicates  that  the 
Operating  Command  action  officer  for  a  project  preparing  for  a  MilestoneReview  is  typically  a  Major  or  Lt 
Colonel.  However,  the  Concept  Action  Group,  per  se,  is  still  a  relatively  new  concept,  and  not  widely 
used. 
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d.  LESSONS  LEARNED:  It  is  desirable  for  the  Project  Office  to  formally  coordinate  with  the 
GAG  prior  to  the  start  of  the  estimating  activity  to  ensure  that  all  programmatic  and  estimating 
assui^ions  are  fcjUy  understood.  Further,  during  the  developm^  of  the  estimate,  the  project  manager 
should  remain  in  clo^  contact  with  the  GAG  to  ensure  that  any  issues  that  might  impact  the  analysis  are 
addressed.  During  the  Operating  Gommand  POM  deliberations  and  reviews,  it  is  important  that  the 
project  martagers  keep  in  dose  contad  with  the  projed  represenlative(s).  This  is  irr^xxtant  to  help 
resolve  issues  that  may  arise,  and  to  ertsure  that  th^  fully  understand  all  the  pertinent  aspects  of  the 
projed  and  can  defend  the  projeded  resource  requirements. 

e.  BEST  PRACTICES:  After  submission  of  the  estimate  to  the  GAG,  the  Projed  Office  should 
posture  itself  to  be  able  to  respond  effedively  to  programmatic  questions  and  to  be  able  to  generate 
quantitative  answers  to  GAG  requests  to  develop  and  price  out  program  variations  and  alternatives.  In 
the  case  of  the  POM,  this  capability  to  gerterate  quality  'what-if*  information  in  a  timely  manner  (often 
within  a  few  hours)  is  important,  since  the  reconciliations  and  rankings  that  must  be  pedormed  by  the 
Operating  Gommand  must  be  supported  in  a  timely  manrter.  The  exercises  may  require  modifickions  to 
the  projed  POM  requests  based  on  changes  in  funding  levels,  quantities,  schedules,  or  other 
programmatic  aspeds.  If  the  Projed  Office  is  unable  to  provide  the  necessary  information,  and  in  time 
to  support  the  decision  makers,  the  projed  may  not  be  supported,  or  approved  with  insufficient  funding 
levels.  Further,  if  the  Projed  O^'  '.e  is  unable  to  provide  a  requested  estimate,  someone  with  even  less 
information  may  generate  one  f  the  projed. 

f.  TRAPS:  If  the  estimate  is  the  first  to  be  presented  to  the  GAG,  it  is  imperative  that  the  projed 
office  fully  understand  the  requirements  of  the  GAG,  especially  in  terms  of  content,  scope,  assumptions, 
and  the  deliverable  produds.  In  the  case  of  the  POM,  if  this  POM  input  is  the  first  for  the  projed,  the 
submission  will  be  considered  a  ‘New  Start,*  and  identified  as  such.  There  may  be  additional 
documentation  requirements  and  a  higher  level  of  scrutiny  and  review  for  these  projeds/programs,  since 

9  there  is  not  an  existing  funding  line.  Due  to  this,  the  projed  office  must  be  especially  prepared  to  defend 
projed  requirements. 
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1.  ELEMENT:  C23,  TBS  1 .2.3.9  (IFC  93-3) 


2.  ELEMENT  TITLE:  Staff  and  Coordinate  Ck)st  and  Operational  Effectiveness  Analysis  (COEA)  I 
Report 

3.  ELEMENT  OWNER(S):  Operating  Command 

4.  ELEMENT  STAKEHOLOER(S):  Secretary  of  the  Air  Force  (SAF)/AQ/FM.  USAF/XOR.  Office  of  the 
Assistant  Secretary  of  Defers  (OASD)  (PA&E),  Air  Force  Materiel  Command  (AFMC),  Under  Secretary 
of  Defense  for  Acquisition,  Air  Force  Sttxfies  and  Analysis  Agency  (AFSAA),  Air  Force  Operational  Test 
and  Evaluation  Center  (AFOTEC),  Product  Center  and  other  organizations  participating  in  COEA I 
development. 

5.  REQUIREMENT: 

a.  AFPD  1 0-6,  Air  Force  Mission  Needs  and  Operaifyonal  Requiremerns,  1 9  Jan  93.  paragrc^sh 
1.6.  This 

paragraph  defines  the  COEA  requirements. 

b.  AFM  0-601 ,  Mesion  Needs  and  Operational  Requirements  Guidance  and  Procedures,  1 6  Feb 
93. 

paragraph  1 .4.  Attachments  5  and  9.  These  paragraphs  explain  how  to  accomplish  a  COEA 
and  the  duration  associated  with  drafting  and  coordinating  of  the  document. 

6.  PURPOSeOBJECnVES: 


appriwal 

\  of  the  d 

b.  Obi. 


.  Purpoee:  To  prepare  and  obtain  Operating  Command  2-Letter  and  external  review  and 


draft  COEA  I  report. 


b.  Objectives:  To  ensure  all  Air  Force  and  other  participants  have  a  say  in  the  COEA  I  Report 
and 

concur  with  the  results.  This  can  then  be  taken  forward  to  HQ  USAF  and  DoD  for  review 
with  a  solid  and  agreed  to  COEA  I  Report  that  is  fully  integrated  with  the  Mission  Need 
Statement(MNS), 

COEA  and  proposed  Operational  Requirements  Document  (ORD). 

7.  DESCRIPTION:  The  Operating  Command  has  responsibility  for  preparing  the  COEA  I  Report  and 
may  contract  out  the  effort,  conduct  it  in-house,  or  ask  the  Acquisition  Command,  usually  Product  Center 
XR  organization,  to  accomplish  the  analysis  and  pr^re  the  COEA  I  Report.  For  the  proper  COEA 
report  format,  see  DOD  5000.2-M,  Defwse  Acquisition  Management  Documentation  and  Reports,  Feb 
91 ,  Part  8,  Attachment  1 .  To  pr^re  this  draft,  the  lead  Operating  Command  must  have  information 
from  and  provide  information  to,  i.e.,  an  iterative  relationship,  C19  and  D37B.  The  draft  COEA  I  Report 
is  then  distributed  to  other  participating  organizations,  including  sister  services  when  the  project  is  a  joint 
effort,  for  review  and  comment  in  accordance  with  AF1 1 0-601  and  incorporating  applicable  commerrts 
into  the  final  COEA  I  Report.  This  document  then  goes  through  an  internal  coordination  process  that 
ends  with  Operating  Command  signature.  The  Draft  Report  is  then  provided  to  Air  Staff  to  prepare  for 
the  requirements  summit,  B14.  HQ  USAF/XOR  reviews  foe  draft  report  for  Air  Force  Acquisition 
Executive  approval  for  potential  Acquisition  Category  (ACAT)  I  programs  and  coordfoates  the  COEA  I 
Report  with  the  OASD  (PA&E)  prior  to  Milestone  I.  PA&E  prepares  a  report  summarizing  the  findings 
and  assessing  whether  all  reasonable  alternatives  were  examined  and  whether  the  costs,  benefits,  and 
risks  were  adequately  addressed.  This  assessment  is  circulated  to  all  Defense  Acquisition  Board  (DAB) 
members.  For  other  ACAT  levels,  the  Operating  Command/CC  approves  the  COEA  I  Report  and 
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submits  it  to  HQ  USAF/XOR  before  a  scheduled  milestorte  review.  HQ  USAF/XOR  then  reviews  the 
COEA I  Report  and  submits  it  to  SAF/AQX  prior  to  Milestorw  I  review. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance  Criteria;  For  C23  to  begin,  the  lead  operating  command  needs  to  know  which 
preferred  alternatives  w^  selected.  C25.  as  well  as  al  the  data  previously  provided  tor  selecting  the 
preferred  altematives.  C25.  D47, 048,  and  049. 

b.  Exit  Criteria:  Finalized  COEA  I  Report  signed  by  the  Operating  Command/CC. 

9.  KEY  INPUTS  ANO  OUTPUTS: 

a.  Inpiris;  Besides  the  information  identified  in  8.a..  the  lead  operating  command  will  continually 
need  to  iterate  its  activities  with  the  team  building  the  Oraft  ORO  I,  C19.  and  the  team  working  the 
concept  definitions  tor  the  preferred  altemative(s),  037B. 

b.  Outputs;  The  primary  output  is  the  Oraft  COEA  I  Report  sigrred  by  the  Operating 
Command/CC  for  submittal  to  be  used  in  preparing  tor  the  summit  review.  Also,  the  report  must  be 
submitted  to  the  team  building  the  Oraft  ORO  I,  C19,  and  the  team  working  the  concept  definitions  for 
the  preferred  altemative(s),  037B  to  ensure  all  the  documentation  is  integrated  when  presented  to 
summit  and  OAB  reviews. 

10.  KEY  REFERENCES: 


♦j 


a.  OOO  5000.2-M,  Defense  Acquis^ion  Management  Documentation  and  Reports,  Feb  91 , 

Part  8.  This  manual  provides  general  procedures  and  guidelines  for  developing  COEAs. 

b.  OOO  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  Feb  91 , 
Part  4,  Section  E.  This  section  provides  the  basis  for  developing  COEA  to  support  Milestone  decision 
reviews. 


c.  AF1 1 0-61 0,  Mission  Needs  and  Operational  Requirements  Guidance  and  Procedures, 

16  Feb  93,  Paragraph  1 .4  and  Attachment  5.  The  instruction  provides  when  to  perform  and  how  to 

prepare  a  COEA  report.  R 

1 1 .  IMPLEMENTATION  TOOLS:  AFMCP  1 73-1 ,  Oraft  AFMC  Cost  S  Operational  Effectiveness 
Analysis  COEA  Handtxxjk,  Oct  92.  Paragraph  2.2.3.  This  handbook  explains  in  detail  steps  involved 
and  specifics  contained  in  COEA  process  and  report. 

12.  PLANNING  GUIDANCE:  • 

a.  DURATION:  The  majority  of  the  effort  in  developing  the  COEA  I  Report  is  sperfi  performing 
the  anaijriical  studies  and  comparative  analysis.  The  documentation  of  the  analysis  should  be 
accomplished  within  180  days  after  'receipt  of  tasking'  (Program  Management  Directive)  in 
accordance  to  AF1 10-601 .  The  COEA  is  the  pacing  item  for  Phase  0  efforts  and  is  usually  event  driven. 

More  time  will  be  required.  The  drafter  should  negotiate  this  schedule  as  early  as  possible,  as  it  win  8 

affect  all  subsequent  events.  Goals  for  achieving  staffing  and  coordination  are  as  follows; 

(1)  50  days  "for  oommenT  review  of  draft  report  (AF1 10-601). 

(2)  14  days  to  incorporate  comments  and  prepare  final  report. 

(3)  21  days  for  study  team  to  brief  the  Corx:ept  Action  Group  (CAG)  which  then  revises 
and  approves  the  report. 
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(4)  35  <teys  for  Memai  coordination  and  Operating  Command/CC  approval.  The  time 
frame  depends  on  the  timing  (4  the  Phase  0  Requirements  Summit.  Milestone  I  and  other  pertinent 
reviews.  The  COEA I  Report  must  be  coordinated,  approved  by  the  operating  commarxj,  and  distributed 
at  least  60  days  before  the  Milestone  I  review,  or  M  days  before  the  Requirements  Sunwnit,  if  a  Summit 
is  scheduled. 

b.  CONSTRAINTS: 

(1)  If  the  lead  operating  conrwnand  does  not  corKluct  a  CAG  to  oversee  the  CC^  effort, 
the  normal  forum  to  get  all  the  stakeholders  involved  and  resolve  arty  issues  prior  to  releasing  the  report 
has  been  eliminaled.  An  extensive  distribution  and  coordination  process  would  be  required  as  an 
aNemative  which  could  extend  the  review  process.  Cross  flow  of  information  is  necessary  in  developHig 
such  a  complex  report. 

(2)  A  major  constraint  could  be  the  action  officer  doesnl  have  any  say  as  to  when  the 
Summit  or  Milestone  I  decision  should  be  scheduled.  In  this  case  the  action  officer  will  be  forced  to 
accomplish  the  staffing  and  coordination  process  within  a  pre-established  schedule. 

c.  RESOURCES: 

(1 )  The  lead  operating  command  should  assign  an  action  officer  to  ensure  aH  sectbns  of 
the  COEA  I  Rep^  are  adequately  addressed  and  applicable  comments  incorporated  from  internal  and 
external  organizations.  A  focal  point  from  each  operating  command  directorate  receiving  the  report  will 
be  required  in  consolidating  their  comrrtents. 

(2)  Functional  representatives  from  external  organizations  receiving  the  report  are 
needed  to  review,  consolidate,  arid  coordinate  their  comments. 

d.  LESSONS  LEARNED: 

(1)  OASD  PA&E  plays  a  major  role  in  the  review  arxf  approval  process.  They  need  to 
be  in  the  loop  long  before  final  review  arxf  approval.  T^  want  to  be  aware  of  the  COEA  I  pMn, 
methodologies  used,  and  any  other  significant  information.  If  you  surprise  them,  it  could  be  disastrous  to 
your  schedule  and  any  previous  work.  On  the  positive  side,  they  can  offer  valuable  lessons  learned  from 
other  service  COEAs.  Involve  them  carefully. 

(2)  The  COEA  I  action  officer  normally  has  his  hands  full  getting  the  document  to  the 
rightpeople  and  ensuring  tasked  organizations  return  comments  on  time.  If  the  Milestone  decision 
meeting  or  Summit  date  has  been  proposed  or  established,  the  action  officer  should  make  a  review  and 
approval  schedule  that  backs  up  from  those  dates.  It's  important  that  this  process  be  carefully  planned 
and  slack  time  be  built  in,  if  possible,  especially  for  potentiaNy  controversial  programs.  To  avoid  this 
situation,  the  action  officer  should  be  proactive  and  recommend  realistic  milestone/summit  dates. 

(3)  The  acquisition  action  officer  wiN  have  the  same  problem  in  responding  to  a 
schedule  set  by  the  lead  operating  command.  The  action  officer  needs  to  work  with  the  lead  operating 
command  to  ensure  comments  and  coordination  are  accomplished  when  needed.  The  action  officer 
should  challenge  unrealistic  schedules. 

(4)  With  all  the  coordination  and  working  of  comments,  there  are  bound  to  be  obstacles 
that  require  extraordinary  effort  to  overcome,  such  as  unforeseen  issues,  politics,  and  other  differences 
of  opinion.  Work  closely  with  coordinatirrg  offices  before  you  formally  coc^inate  with  them.  Stay  within 
the  bounds  of  approved^alidated  threats  and  scenarios. 

(5)  No  procedures  for  conducting  and  coorr^nating  a  joint  COEA  have  been  established. 
This  may  cause  pi^lems  in  not  identifying  the  appropriate  stakehokJ^  and  possibly  missing  key  and 
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unique  Mormalion.  If  the  i^iprapnate  stakeholders  are  not  invotved  up  front,  then  there  is  a  poterSial  tor 
delays  in  obtaininQ  coordination. 

e.  BEST  PRACTICES: 

(1)  The  lead  operating  command  action  officer  should  ensure  ail  ^akeholders  are 
involved  in  thereview  and  coordination  process  and  HQ  USAF/XOR  is  kept  in  the  loop-  The  lead 
operating  command  action  officer  could  expedite  tNs  process  by  providing  realistic  (event-driven) 
coordination  and  approval  schedules.  The  acquisition  action  officer  also  has  stakeholders  that  shouktol 
be  left  out.  An  important  stakeholder  who  didnl  get  to  comment  can  come  back  to  haunt  you. 

(2)  Each  action  officer  should  establish  deadlines.  However,  the  lead  operating  command  should  wait 
tor  critical  comments,  such  as  those  from  HQ  USAF/XOR.  SAF/FMC.  SAF/AQX.  AFOTEC.  and  AFSAA 
before  proceeding  on  to  the  next  phase. 

(3)  The  lead  operating  command  action  officer  needs  to  follow  up  on  receipt  of  the 
COEA I  report,  and  status  of  e^  reviewing  organization's  progress. 

(4)  The  000  component,  in  the  process  of  performing  a  milestone  I  COEA.  should 
identify  the  Measures  of  Effectiveness  (MOE)  to  be  used  and  show  how  these  MOEs  are  derived  from 
the  MNS.  Each  COEA  should  include  MOEs  reflecting  operational  utility  that  can  be  tested.  For  those 
MOEs  that  canmt  be  directly  tested,  the  COEA  should  show  how  changes  in  testable  parameters  or 
measures  of  performance  can  be  related  to  changes  in  COEA  MOEs. 

f.  TRAPS: 

(1 )  The  action  officer  shouldn't  make  the  assumption  that  aH  organizations  wiN  be 
responsive  with  th^r  comments/coordination.  Maintain  frequent  contact  with  aH  applicable  organizations. 

(2)  The  lead  operating  command  needs  a  a>ntract  vehicle  to  accomplishe  COEAs  if 
they  electnot  to  use  AFMC  tor  this  effort.  The  grating  command  needs  to  determine  their  COEA 
process  and  associated  funding.  This  would  eKminate  any  delays  due  to  lack  of  funrJing. 
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1.  ELEMENT:  C2S.  TBS  1 .2.37  (IFC  93-3) 

2.  ELEMENT  TITLE:  Select  Prsferred  Allemative(s) 

3.  ELEMENT  OWNER(S):  Operating  Command 

4.  ELEMENT  STAKEHOLOER(S):  AFMC.  AFOTEC.  SAF/FMC.  AFSAA.  USO(A).  OASO  (PA&E). 
AF/XOR. 

5.  REQUIREMENT:  DOO  5000  series,  Air  Force  Instruction  10-601 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose:  For  the  operating  command's  commander  (or  desigiuae)  to  select  a  concefX  alternative 
or  alternatives  that  satisfy  the  user's  need  and  the  approach  that  will  be  proposed  as  an  acquisition 
program. 

b.  Objectives:  For  the  Concept  Action  Group  (CAG)  or  other  assembly  to  nuAe  a  recommendation 
to  the  commander  for  selection  of  a  preferred  altemative  based  on  the  findhigs  of  the  Cost  and 
Operational  Effectiveness  Analysis  (COEA). 

7.  DESCRIPTION:  The  Concept  Action  Group  (CAG)  or  equivalent  has  completed  its  extensive 
exploration  of  possible  materiel  alternatives  and  documented  the  results  in  the  Cost  and  (Operational 
Effectiveness  Analysis  (COEA)  Report  (D48).  the  Program  Alternatives  Analysis  (D46).  and  Program 
Cost  Estimate  (D47)  before  briefing  the  operating  command's  commander  (or  designate).  The  COEA 
also  documents  the  CAG's  rationale  for  their  recommendation  for  preferred  concept  altemative(s)  which 
will  become  the  basis  for  a  project's  Milestone  l/IV  documentation-  such  as  the  System  Threat 
Assessment  Report  (STAR  -  050),  Acquisition  Program  Baseline  (APB  -  051),  Ciost  Analysis 
Requirements  Oescription  (CARO  -  052),  Operational  Requirements  Oocument  (ORO  -  C19),  and  the 
Test  and  Evaluation  Master  Plan  (TEMP  -  054).  Until  this  actual  selection  of  concept  altentativefs)  as 
solution(s)  to  meeting  the  user's  needs  by  the  operating  command's  commander  (or  designate),  all  of  the 
documentation  for  an  eventual  Milestone  l/IV  d^ision  has  been  generic  in  content  and  will  have  to  be 
updated  to  reflect  the  attemative(s)  selection. 

8.  ENTRANCBEXIT  CRITERIA: 

a.  Entrance:  Oraft  COEA  completed  with  the  CAG's  recommendation  for  preferred  concept 
altemative(s). 

b.  Exit:  Operating  command's  selection  of  concept  altemative(s)  as  the  preferred  solution(s)  that 
satisfy  the  user's  need. 

9.  KEY  INPUTS/OUTPUTS: 

a.  Inputs:  Draft  COEA  (D48)  and  draft  ORO  (C19). 

b.  Outputs:  Preferred  aKemative  solution(s),  updated  COEA  Report  approved  by  the  operating 
command. 

10.  KEY  REFERENCES:  DODO  5000.1 ;  DODI  5000.2,  DOD  5000.2-M;  AFI  10-601 ;  AFMCP-173-1 , 
AFMC  COEA  Handbook,  August  1992. 

11.  IMPLEMENTATION  TOOLS:  None  identified. 
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12.  PLANMNG  QUiOANCE: 

a.  DURATION:  The  actual  selection  of  the  concept  allemative(8)  that  wiH  be  proposed  as  an 

acquisition  program  most  Ikely  will  be  done  during  the  briefing  to  the  operating  command's  commander  i 

or  designate  based  on  the  CAG's  recommendations.  The  CAG's  preparation  for  this  briefing  varies  with 
the  size  and  complex^  of  the  project,  the  number  of  akematives  studied  in  the  COEA,  and  the  detail  to 
which  the  commander  needs  information  to  make  a  justifiable  selection. 

b.  CONSTRAINTS:  None  identified. 

» 

c.  RESOURCES:  The  briefing  to  the  operating  command's  commander  (or  designarte)  should  be 
attended  by  the  command's  two-letter  council  participants  or  their  representatives. 

d.  LESSONS  LEARNED:  None  identified. 

e.  BEST  PRACTICES:  The  CAG  should  be  sure  that  ait  of  its  participants  agree  on  their  I 

recommendation  of  the  preferred  altemative(s)  that  wiN  be  proposed  as  an  acquisitbn  program  and  the 

groundiules  and  assumption  upon  which  the  selection  was  made.  This  recommendation  to  the  operating 
command's  commander  (or  designate)  should  be  coordinated  throughout  the  applicable  organizations 
within  the  commarKf  so  that  there  are  no  surprises  during  the  actual  briefing. 

f.  TRAPS:  None  identified.  m 
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1.  ELEMENT:  C26.  TBS  1 .2.2.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Staff  and  Coordinate  Operational  Requirements  Document  (ORD)  I  (User) 

3.  ELEMENT  OWNER(S):  AF/XOR 
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4.  ELEMENT  STAKEHOLOER(S):  AF/XOR,  Operating  Conmand.  Implementing  Command,  AFOTEC, 
Participating  Commands. 

5.  REQUIREMENT: 

a.  AFPD  10-6,  Mission  Needs  and  Operational  Requirements.  19  Jan  93,  Attachment  3,  identifies 
ORD  approval  rer^iremerffs. 

b.  OODI  5000.2,  Defense  Acquisition  Management  Policy  and  Procedures,  23  Feb  91 ,  Part  4 
(Section  B),  describes  procedures  for  JROC  validation  of  system  performance  requirements. 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose:  Staff  and  coordinate  the  ORD. 

b.  Objective:  Approve  the  ORD. 

7.  DESCRIPTION:  An  initial  ORD  must  be  prepared  in  response  to  the  Milestone  0  Program 
Management  Directive  (PMD).  The  Operating  Command  is  responsible  for  the  ORD.  After  the  ORD  is 
drafted  (Cl  9),  the  Operating  Command  distributes  it  for  staffir>g  and  coordination  in  accordance  with  AFI 
10-601  arxf  local  procedures  (see  below).  The  ORD  is  approved  by  the  Chief  of  Staff  of  the  Air  Force 
(CSAF)  after  successful  staffing  and  coonjination.  The  ORD  is  the  source  of  perfonnance  requirements 
for  the  APB  (D51 )  and  TEMP  (DS4).  The  ORD  is  also  a  major  document  reviewed  at  the  Requirements 
Summit  (ACAT  I)  (B14  and  BIS). 

After  the  ORD  is  drafted  (Cl  9),  the  using  command  OPR  distributes  it  ’for  comment’  in  accordance 
with  AF1 1 0-601 .  Inputs  are  normally  required  within  45  days  of  receipt  by  addressees.  AF/XOR,  one  of 
the  addressees,  distributes  all  ORDs  for  review  and  comment  to  the  Air  Staff  and  Secretariat,  affected 
Services,  CINCs,  and  Defense  agencies,  and  provides  a  consolidated  position  to  the  OPR  within  45 
days.  The  second  ORD  phase  of  review  is  the  final  ’coordination’  phase.  The  using  command 
co^inates  changes  from  the  *for  comment’  phase  with  all  reviewing  organizations. 

The  OPR  then  finalizes  the  ORD  (final  internal  coordination),  prepares  it  for  operating  MAXOM/CC 
approval,  and  submits  it  to  AF/XOR  for  CSAF  approval  at  least  60  days  before  the  Summit  (ACAT  I) 
(B14).  All  ORDs  require  CSAF  approval. 

After  the  ORD  is  approved  and  published,  the  OPR  will  distribute  it  and  not  change  the  ORD  without 
coordinating  with  the  applicable  OCRs,  including  AF/XOR.  The  OPR  will  change  the  ORD  after  Summit 
and  Milestone  Reviews  as  required. 

The  Joint  Requirements  Oversight  Council  (JROC)  may  retain  ORD  validation  and  approval 
authority  for  some  ACAT  I  programs,  but  usually  delegates  this  authority  to  the  appropriate  Service 
Chief.  The  JROC  will  review  the  key  parameters  from  the  ORD  that  will  be  included  in  the  Acquisition 
Program  Baseline  (APB).  Approved  ORDs  are  submitted  by  the  approval  authority  to  the  appropriate 
Milestone  Decision  Authority  (MDA)  for  action.  Validation  in  this  case  confirms  that  the  capabilities 
provided  by  the  proposed  system  will  fulfill  the  mission  need.  It  also  confirms  that  there  is  no  other 
materiel  altemative  which  will  meet  the  need  (including  another  Service  or  Allied  system).  Approval 
constititutes  formal  sanction  and  certification  of  the  requirements  document  (ORD). 
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a  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Start  iormal  staffing  arxf  coordination  when  the  COEA  has  been  approved  by  CSAF 
and  the  ORO  has  been  drafted. 

b.  Exit;  End  when  the  ORD  has  been  approved  by  CSAF. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  CSAF  a|H3(oved  COEA  and  Draft  ORO. 

b.  Output;  CSAF  approved  ORD. 

10.  KEY  REFERENCES:  In  addition  to  required  documents  (see  Paragraph  5),  AF1 10-601 .  Mission 
Needs  and  Operational  Requirements  Guidance  and  Procedures,  16  Feb  93,  Attachment  6,  identifies 
ORD  staffing  and  coordination  procedures. 

11.  IMPLEMENTATION  TOOLS:  Individual  using  commands  have  local  procedures. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  AF1 10-601  states  the  draft  ORD  should  normally  be  prepared  within  180  days  of 
tasking  (see  12.b.,  12.d.,  and  12.f.  for  caution  in  using  this  as  planning  ^idance).  This  180  days 
iTKludes  draft  preparation  time  and  time  for  operating  commarxf  DCS  signature.  Following  DCS 
signature,  approximately  90  days  are  required  as  follows; 

45  days  Tor  comment*  review 
1 5  days  to  work  comments 

30  days  for  final  coordination  and  using  MAJCOM/CC  approval. 

b.  CONSTRAINTS:  A  major  constraint  is  the  Cost  and  Operational  Effectiveness  Analysis  (COEA). 
Completion  of  the  ORD  depends  on  completion  and  aftproval  of  the  COEA  by  the  operating 
MAJCOM/CC  and  CSAF.  If  a  schedule  for  the  ORD  has  been  downward  directed,  seek  schedule  relief 
as  soon  as  the  COEA  looks  like  it  may  impact  the  schedule  for  completing  the  ORD.  Inform  AF/XOR. 

AR  10-601  states  that  the  180-day  suspense  can  by  waived  depending  on  COEA  accomplishment, 
milestones,  reviews,  arxf  summits,  etc.  The  180  days  is  arbitrary  and  capricious  and  should  be 
challenged.  The  driver  is  getting  a  quality  COEA  from  which  the  ORD  will  be  derived. 

c.  RESOURCES:  One  action  officer  (a/o)  will  be  required  at  the  operating  command  (maybe  more 
than  one  depending  on  the  size  and  visibility  of  the  program)  to  plan,  initiate,  and  conduct  the  review  and 
approval  process.  An  a/o  will  be  required  from  each  organization  receiving  the  ORD  from  the  operating 
command  for  comment  and  coordination.  Functional  and  project  representatives  from  each  directorate 
of  each  organization  receiving  the  ORD  from  the  operating  commarid  are  needed  to  review,  comment, 
and  coordinate. 

d.  LESSONS  LEARNED:  The  ORD  a/o  at  the  operating  command  normally  has  his  hands  full 
getting  the  document  to  the  right  people  and  ensuring  tasked  organizations  return  comments  in  a  timely 
manner.  The  a/o  is  normally  handling  several  other  ORDs  simultaneously.  The  a/o  should  make  a 
realistic  review  and  approval  schedule  that  considers  accomplishment  of  the  COEA  and  timing  of 
milesk>nes,  reviews,  and  summits.  It's  important  that  this  process  be  carefully  planned  and  slack  time  be 
built  in,  if  possible,  especially  for  potentially  controversial  programs. 

The  Product  Center  a/o  must  be  responsive  to  the  schedule  set  by  the  a/o  at  the  operating 
command.  Work  together  to  establish  the  schedule  and  ensure  you  get  comments  and  coordination 
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when  needed.  It  is  importarN  you  understand  what  is  driving  completion  of  the  review  and  challenge 
arbitrary  schedules.  Balance  the  need  to  accomplish  the  review  by  a  certain  date  with  the  need  to 
accom^ish  a  quality  review. 


Consider  the  following  when  reviewing  the  ORD.  (1 )  Do  the  broad  objectives  and  minimum 
acceptable  requirements  (thresholds)  define  system  capabilities  that  will  satisfy  the  need  described  in  the 
MNS?  (2)  Are  the  objectives  and  thresholds  in  the  APB  and  TEMP  consistent  with  the  ORO  (the  ORD 
must  be  the  source  of  requirements  in  these  documents)?  (3)  Do  the  objectives  and  thresholds  leave 
room  for  an  orderly  evolutionary  development  of  the  system  (trade  studies  and  testing  in  Phase  I  will 
result  in  thresholds  and  objectives  for  more  refined  capabilities  and  characteristics).  (4)  Are  the 
requirements  testable?  (5)  Is  the  format  corect? 

With  all  the  coordination  and  working  of  comments,  there  are  bound  to  be  obstacles  that  require 
extraordinary  effort  to  overcome,  such  as  unforeseen  issues,  turf  battles,  and  other  differences  of 
opinion.  This  is  especially  true  if  the  ORD  is  a  Joint  ORD. 

e.  BEST  PRACTICES:  Ensure  all  stakeholders  are  involved  in  the  review  and  coordination  process 
arKl  are  aware  of  the  coordination  and  approval  scheckjle.  The  Product  Center  a/o  has  stakeholders  that 
shoukfnl  be  left  out  (i.e..  Office  of  Aerospace  Studies,  respective  Air  Logistics  Center,  XR,  YX,  related 
SPOs,  functional  two-letters.  An  important  stakeholder  who  didn't  get  to  comment  can  come  back  to 
haunt  you. 

The  operating  command  a/o  should  follow  up  with  all  reviewers,  but  especially  with  those  whose 
comments  or  coordination  are  needed  the  most.  The  most  critical  comments  will  be  those  made  by 
AF/XOR,  AFMC,  ATC  and  AFOTEC.  Don't  proceed  to  the  rwxt  phase  without  them.  The  Product  Center 
a/o  should  also  ascertain  whose  comments  are  critical.  Take  a  look  at  whose  coordination  or  approval 
you'll  want  or  need  downstream  and  get  involved  with  them  early  and  often. 

I.  TRAPS:  The  a/o  shouldn't  assume  that  all  organizations  will  comment/coordinate  promptly.  To 
stay  on  schedule,  the  a/o  must  stay  in  dose  contact  with  the  organizations  whose  coordination  or 
cooperation  are  needed  the  most  (long  poles). 

While  schedule  may  be  a  good  motivator  for  getting  the  job  done,  it  should  not  be  allowed  to  inhibit  a 
quality  review.  This  activity  should  be  primarily  concerned  about  getting  a  quality  review.  Strike  the 
right  balance. 
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1.  ELEMENT:  C27.  TBS  1 .2.4  5.3  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  Cost  Estimate  and  Update  Budget  Request  [CC#  93-0117] 

3.  ELEliENT  OWNER:  Operating  Command 

4.  ELEMENT  STAKEHOLl>ER(S):  SAF/AQ/FMB,  AF/XOR,  Project  Manager 

5.  REQUIREMENT:  OoO  Directive  7045.14,  The  Plannir>g,  Programmirtg,  and  Budget  System  (PPBS), 
22  May  84,  and  Air  Force  Instmction  10-601 ,  paragraph  1 .2.3. 


6.  PURP0SE/0BJECTIVE(S): 

a.  Purpose:  The  purpose  of  this  activity  is  to  obtain  Operating  Command  approval  for  the 
projea  office  estimate  of  the  preferred  program  attemalive. 


b.  Objective:  Get  the  program  office  cost  estimate  included  into  the  Air  Force  budget, 
submitted  for  an  Air  Force  Requirements  Summit,  or  approved  for  use  to  support  other  exercises,  as 
appropriate. 


7.  DESCRIPTION:  At  this  point  in  the  project,  the  Operating  Command  preferred  altemative(s) 
selection  (C25),  the  preliminary  Acquisition  Program  Baseline  (D51),  and  the  Cost  Analysis 
Requirements  Description  (D52,  as  required)  will  have  been  complied.  Based  on  this,  a  Project  Office 
Program  Cost  Estimate  (D53)  should  be  generated  to  document  the  financial  requirements  for  the 
preferred  program  alternative.  For  a  major  acc^isition  program,  or  any  others  selected  to  participate  in 
an  Air  Force  Requirements  Summit  (B15),  the  estimate  is  a  required  input  for  the  Summit  Preparation 
(B14).  Additionally,  if  there  is  an  Air  Force  Program  Objective  Memorandum  (POM)  exercise  planned 
(B16),  the  estimate  should  be  updated  as  required  for  inconsoration  into  the  Operating  Command  POM 
submission. 


a.  There  are  two  activities  in  this  element.  First,  the  project  office  estimate  of  the  program 
should  be  completed  and  provided  to  the  Operating  Command  for  review  and  approval.  This  should  be 
accomplished  prior  to  the  use  of  the  estimate  for  budg^  submissions  or  other  planning  activities.  The 
review  should  be  accomplished  to  assure  that  the  estimate  is  representative  of  the  program  that  will  be 
recommended  to  address  the  Command's  operational  deficiencies.  The  magnitude  and  extent  of  the 
review  could  be  expected  to  vary,  based  on  the  ACAT  level  of  the  program,  the  magnitude  of  the 
program  costs,  and  the  general  level  of  interest  in  the  program.  The  project  OPR  in  the  Operating 
Command  should  be  responsible  for  coordinating  the  specific  review  requirements.  If  the  Operating 
Command  has  established  a  Concept  Action  Group  (CAG)  to  direct  and  oversee  the  project’s  Phase  0 
stu^  activities  (Cl 6),  the  CAG  should  perform  this  function,  if  the  CAG  has  been  given  the  authority  to 
review/approve  the  project  activities.  For  the  purpose  of  this  discussion,  it  is  assumed  that  a  CAG  has 
been  established.  In  the  case  of  projects  that  have  been  selected  to  participate  in  an  Air  Force  Summit 
review,  the  CAG  should  ensure  that  any  specific  Summit  requirements,  such  as  estimating  excursions, 
have  been  performed. 

b.  Second,  when  there  is  an  opportunity  to  get  the  approved  program  estimate  incorporated  into 
the  Operating  Command's  POM  submission  to  Air  Staff  (B16),  this  should  be  accomplished  to  get  the 
proje^  funding  requirements  approved.  To  achieve  this,  the  CAG  should  work  with  the  Project  Office  to 
ensure  that  a  POM  input  is  developed  which  meets  the  current  CAG  requirements  and  can  be  supported 
in  the  Operating  Command  POM  review  process.  (Note:  Since  a  delay  may  occur  between  the  estimate 
completion  (and  approval)  and  the  POM  submission,  fact  of  life  changes  may  require  the  project  office  to 
develop  and  submit  program  and  estimate  variations  in  the  POM).  When  the  POM  inputs  are  received 
from  the  Product  Centers,  the  CAG  should  be  prepared  to  address  program  issues,  and  support  the 
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project  in  the  review  process.  Further,  a  CAG  representative  should  serve  as  the  interlace  with  the 
Project  Office  when  additional  information  or  analysis  excursions  are  required. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  ENTRANCE:  The  need  for  the  effort  descrtoed  above  depends  on  the  anticipated  ability  to 
interject  the  estimated  project  costs  into  the  Air  Force  POM  (B16),  the  scheduling  of  an  Air  Force 
Summit  (B14),  or  based  on  a  CAG  requirement  placed  on  the  Project  Office  to  generate  a  program 
estimate(s)  to  support  planning  activities. 

b.  Exit:  Approval  of  the  project  office  estimate  by  the  Operating  Command  for  submission  into 
the  Summit  review  process  (B15),  or  input  into  the  Air  Force  POM  process  (B16). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  primary  input  for  the  estimate  review  are  the  Project  Office  Program  Cost 
Estimate  (D53).  Additionally,  the  results  of  the  Operating  Command  preferred  altemative(s)  selection 
(C25),  and  the  documentation  of  the  Cost  Analysis  Requirements  Description  (D52,  if  available),  should 
be  valuable  inputs  to  the  estimate  review.  The  POM  inputs  would  include  the  MAJCOM  specific  BPPBS 
baseline,  normally  received  in  the  spring  of  the  odd-nurr^red  years,  and  the  POM  Preparation 
Instnjctions,  normally  received  from  AF/PE  in  the  summer. 

b.  Outputs:  An  approved  project  estimate  for  planning  purposes,  for  Requirements  Summit 
preparation  (B14)  and  execution  ((B15),  or  for  inclusion  into  the  Operating  Command  POM/BES 
submission  to  Hq  USAF  (B16). 

10.  KEY  REFERENCES:  The  references  below  provide  more  specific  implementation  guidance. 

a.  AFP  172-4,  The  Air  Force  Budget  Process,  Oct  87  -  Describes  the  Air  Force  budget  process. 

b.  DoDI  7045.7,  Implementation  of  the  Planning,  Programming,  and  Budgeting  System  (PPBS), 
23  May  1984  -  Describes  the  budget  process  within  the  Department  of  Defense. 

11.  IMPLEMENTATION  TOOLS:  The  PPBS  Primer,*  7th  Edition.  May  1993.  This  document,  is 
published  by  the  Directorate  of  Programs  and  Evaluation,  Department  of  the  Air  Force,  and  provides  a 
valuable  de^ription  of  the  current  BPPBS  process.  This  is  one  of  the  few  documents  that  describes  the 
current  process,  and  it  does  so  in  detail.  Further,  it  defines  the  activity  schedule  for  the  development  of 
the  FY96  POM.  However,  there  is  not  a  great  deal  of  information  on  POM  preparation  at  the  field  level. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  time  required  for  the  CAG  review  of  the  estimate  can  be  expected  to  be 
related  directly  to  the  level  of  communication  between  the  CAG  and  the  project  office,  the  level  of 
program  definition,  the  approval  of  previous  Project  Office  estimates,  and  the  quality  of  the  project  office 
estimate  and  the  estimate  documentation.  If  the  Project  Office  efforts  have  been  w^l  coordinated  with 
the  CAG,  the  review  may  be  accomplished  with  a  briefing  on  the  estimate,  or  providing  the  analysis 
documentation  to  the  CAG.  However,  if  issues  exist,  the  CAG  review  may  be  performed  over  the  period 
of  weeks,  or  longer,  if  the  Project  Office  is  tasked  to  perform  further  analysis.  In  the  case  of  the  POM, 
the  Operating  Command  activities  begin  in  the  spring  with  the  receipt  of  the  MAJCOM-specific  resource 
baseline  and  end  with  the  submission  of  the  POM  to  Hq  USAF  in  August-September. 

b.  CONSTRAINTS:  The  Project  Office  cost  estimate  will  probably  need  to  be  performed  at  a 
very  high  level  (not  detailed)  due  to  lack  of  program  definition.  B^use  of  the  top  level  approach,  the 
estimating  methods  may  not  always  be  sensitive  to  estimating  excursions  required  by  the  CAG. 
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Additionally,  the  constraints  inherent  in  the  respective  POM  resource  baseline  may  limit  the  Operatmg 
Command's  ability  to  support  the  desired  program. 


c.  RESOURCES:  The  composition  ot  the  CAG  can  be  expected  to  relate  directly  to  the  level  of 
interest  in  the  project,  projected  costs,  and  complexity.  A  sampling  of  projects  indicates  that  the 
Operating  Command  action  officer  for  a  project  preparing  for  a  milestone  review  is  typically  a  Major  or  Lt 
Colonel.  However,  the  Concept  Action  Group,  per  se,  is  still  a  relatively  new  corx:e|:M,  and  not  wi^y 
used. 


d.  LESSONS  LEARNED:  It  is  desirable  for  the  Project  Office  to  formally  coordinate  with  the 
CAG  prior  to  the  start  of  the  estimating  activity  to  ensure  that  all  programmatic  and  estimating 
assumptions  are  fuHy  understood.  Further,  during  the  development  of  the  estimate,  the  Project  Manager 
should  remain  in  close  contact  with  the  CAG  to  ensure  that  any  issues  that  might  impact  the  analysis  are 
addressed.  During  the  Operating  Command  POM  deliberations  and  reviews,  it  is  important  that  the 
Project  Managers  keep  in  close  contact  with  the  Project  Representative(s).  This  is  important  to  help 
resolve  issues  that  may  arise,  and  to  ensure  that  they  fully  understand  all  the  pertinent  aspects  of  the 
project  and  can  defend  the  projected  resource  requirements. 

e.  BEST  PRACTICES:  After  submission  of  the  estimate  to  the  CAG,  the  Project  Office  should 
posture  itself  to  respond  effectively  to  programmatic  questions  and  to  be  able  to  generate  quantitative 
answers  to  CAG  requests  to  develop  arxf  price  out  program  variations  and  alternatives.  In  the  case  of 
the  POM,  this  capability  to  generate  quality  ‘what-ir  information  promptly  (often  within  a  few  hours)  is 
importarrt,  since  the  reconciliations  arid  rankings  that  rrujst  be  perform^  by  the  Operating  (^mmanid 
must  be  supported  in  a  timely  manner.  The  exercises  may  require  rrxxjifications  to  the  project  POM 
requests  based  on  changes  in  funding  levels,  quantities,  schedules,  or  other  programmatic  aspects.  If 
the  Project  Office  is  unable  to  provide  the  necessary  information,  and  in  time  to  support  the  decision 
makers,  the  project  may  not  be  supported,  or  approved  with  insufficient  funding  levels.  Further,  if  the 
Project  Office  is  unable  to  provide  a  requested  estimate,  someone  with  even  less  information  may 
generate  one  for  the  project.  If  the  CAG  review  is  being  performed  to  support  Summit  preparations,  the 
Project  Office  must  have  the  same  capabilities  to  perform  program  analyses,  since  the  project  office 
must  be  capable  of  responding  to  issues  that  arise  during  the  program  reviews. 

f.  TRAPS:  It  is  imperative  that  the  project  office  fully  understand  the  requirements  of  the  CAG, 
especially  in  terms  of  content,  scope,  assumptions,  and  the  deliverable  products.  In  the  case  of  the 
POM,  if  the  POM  input  is  the  first  for  the  project,  the  submission  will  be  considered  a  ‘New  Start,*  and 
identified  as  such.  There  may  be  additional  documentation  requirements  arx)  a  higher  level  of  scrutiny 
and  review  for  these  programs,  since  there  is  not  an  existing  funding  line.  Due  to  this,  the  Project  Office 
must  be  especially  prepared  to  defend  project  requirements. 
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1.  ELEMENT:  C29.  TBS  1.2.3.10  (IFC  93-3) 

2.  ELEMENT  TITLE:  Brief  COEAResuHs  to  OSD(PA&E) 

3.  ELEMENT  OWNER:  Using  Command 

4.  ELEMENT  STAKEHOLOER(S):  Assistant  Secretary  of  Defense  (Prof^m  Analysis  and  Evaluation) 
(ASD(PAAE)),  Operating/Using  Commands. 

5.  REQUIREMENT:  ASD/PA&E's  Draft  Cost  and  Operational  Effectiveness  Analysis  (COEA) 
Guidelines.  Feb  90. 

6.  PURPOSEyOBJECTIVES: 

a.  Purpose:  The  purpose  of  this  element  is  to  brief  Milestone  Decision  Authonty(MDA)  on 
COEA  results. 

b.  Objective:  The  objective  of  this  element  is  to  ensure  MDA  staff  understands  the  report 
before  they  finalize  their  assesssment  of  the  COEA's  adequacy. 

7.  DESCRIPTION:  When  a  COEA  is  forwarded  to  the  Office  of  the  Secretary  of  Defense  (OSD),  it  is 
referred  to  the  appropriate  Defense  Acquisition  Board  (DAB)  committee  (A20).  Prior  to  the  scheduled 
milestone  review,  the  ASD(PA&E)  prepares  a  report  for  the  DAB  assessing  whether  the  COEA  has 
examined  all  reasonable  alternatives  arxf  adequately  evaluated  their  costs,  risks,  and  benefits  (A21 ). 

This  assessment  becomes  part  of  the  "Blue  Book*  that  is  circulated  to  DAB  principals  before  the 
milestone  review.  At  least  3  weeks  before  the  DAB  meets,  the  COEA  team  leader  briefs  the  OSD  staff 
on  the  COEA's  findings.  This  briefing  is  similar  in  style  and  structure  to  the  cost  briefings  of  OSD's  Cost 
Analysis  Improvement  Group  (CAIG).  A  senior  mernber  of  the  OASD(PA&E)  staff  usually  chairs  the 
CO^  briefings. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance: 

(1)  COEA  report  approved  by  the  lead  MAJCOM/CC,  CSAF  and  the  Air  Force  cquisition 
Executive  (B1 5  and  B24). 

(2)  Air  Force  approved  COEA  report  submitted  along  with  other  documentation  45  days 
before  a  DAB  committee  review  (A18). 

b.  Exit:  OASD(PA&E)  understands  and  agrees  wtth  the  COEA  report. 

9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs: 


deficiency 


direction 

(B15). 


1 .  Current  and  complete  user  operational  concept  that  is  consistent  with  mission 

(B15). 

2.  System  threat  assessment,  and  solutions  under  consideration  (B1 5). 

3.  Confirm  funding,  priorities,  schedules  system  baselines,  resources  and  overall 

and  management  effects  are  adequate  (B1 5). 

4.  Establish  achievable  and  affordable  performance  and  support  goal  and  thresholds 

5.  Resolve  major  operational  and  technical  issues  (B15). 

6.  CSAF  COEA  I  and  ORD  I  approval  (B15). 
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b.  Outputs:  ASD<PA&E)  prsparM  report  summarizing  the  lirxlinQs.  assessing  wrhether  al 
reasonable  aRematives  have  been  exwnined.  and  whether  the  costs,  benefits,  and  risks  have  been 
adequately  addressed.  The  report  should  also  include  a  statement  on  the  adequacy  of  the  models  and 
database  used  in  the  COEA. 

This  assessment  is  included  in  the  DAB  Committee  Blue  Book  for  consideration  by  the 
appropriate  DAB  Committee  Review  (A20). 

10.  KEY  REFERENCES: 

(a)  OoO  Directive  5000.4,  *OSD  Cost  Analysis  Improvement  Group  (CAIG),’  24  Nov  92.  Explains  OSD 
CAIG's  responsibilities,  reporting  requirements,  and  membership.  Includes  explartalion  of  requkements  for 
various  acquisition  categories. 

(b)  DoD  5000.2-M,  'Defense  Ac^isition  Management  Documentation  and  Reports,'  Part  8.  Feb  91 . 
Provides  guidance  on  preparing  and  reviewing  a  COEA.  This  includes  a  discussion  on  the  DAB  review 
processes  for  COEAs. 

(c)  DoD  5000.2,  'Defense  Acquisition  Management  Policies  arxt  Procedures,'  Part  13  23  Feb  91 . 
Provides  guidelines  for  briefirtgs  to  the  OSD  CAIG. 

(d)  AFMCP  173*1 ,  AFMC  Cost  &  Operal'nnal  Effectiveness  Analysis  (COEA)  Guide,  30  Dec  92. 
Describes  when  COEAs  are  required,  how  they  are  used,  key  elements,  organizational  stnxffure,  and 
agency  responsibilities. 

(e)  ASD{PA&E)s  Draft  Cost  and  Operational  Effectiveness  Analysis  (COEA)  Guidelmes,  Feb  90. 
chapter  5.  Discusses  the  COEA  review  process. 

(0  AF1 10-601 ,  Mission  Needs  and  Operational  RecMirements  Guidance  and  Procedures,  16  Feb 
93,  Chafer  1  and  attachment  5.  Provides  the  procedures  and  format  for  preparing  arxf  reviewing  a 
COEA. 

11.  IMPLEMENTATION  TOOLS:  None  kJentffied 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  ASO(PA&E)s  draft  COEA  guidelines  indicate  a  COEA  findings  briefing  is  similar 
in  style  and  stmcture  to  the  cost  briefings  to  the  OSD  CAIG.  A  typical  OSD  CAIG  briefing  will  last  2 
hours.  DODD  5000.2,  Part  13.  Section  C.  provides  a  rough  agenda. 

b.  CONSTRAMTS:  COEA  report  and  findings  must  be  proved  by  the  lead  MAJCOM/CC, 

CSAF,  and  the  Air  Force  Acquisition  Executive  before  the  COEA  is  submitted  as  part  of  the  milestone 
draft  documentation. 

c.  RESOURCES:  AFMC  as  the  implementing  command  will  probably  be  asked  to  play  a  big 
role  in  the  development  of  the  COEA  and  will  probably  be  asked  to  help  prepare  the  COEA  briefing  to 
OSD(PASE). 

d.  LESSONS  LEARNED: 

(1)  If  a  COEA  is  to  be  acceptable  and  useful,  its  submission  most  likely  will  have  been 
preceded  by  a  long  and  close  working  relationship  between  the  service  and  OSD  staffs.  The 
OASD(PA&E)  staff  typically  reviews  the  terms  of  reference  for  a  COEA  early  in  the  process,  not  long 
after  Milestone  0  approval. 
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(2)  StafMevei  discussions  should  begin  as  the  COEA  is  being  structured-when 
assumptions  are  being  oonsideied,  aMematives  outlined,  and  measures  of  effectiveness  developed.  H 
the  service  appoints  a  Study  Advisory  Group  (SAG),  it  is  beneficial  to  include  OSD  representatives  oi 
the  SAG. 

e.  BEST  PfUCnCES: 

(1)  Get  OSD  representatives  involved  early  and  keep  them  involved.  This  should  help 
their  review  of  the  final  product  go  smoothly. 

(2)  Deliver  the  COEA  report  on  time.  OSD's  review  of  COEAs  is  critical  to  informed 
DAB  decisions,  the  delivery  and  briefing  dates  are  important.  In  most  cases,  the  DAB  wiN  delay  its 
review  if  a  COEA  in  not  submitted  on  time. 

f.  TRAPS:  The  (POE)/Component  Cost  Analysis  (CCA)  may  be  revised  up  to  the  last  minute 
prior  to  the  CAIG  reviews.  It  is  important  that  the  analj^  <^ief  aN  affected  teams  appraised  of 
changes  or  problems  and  that  oornprehensive  explanations  of  estimate  differerK:es  be  provided  to  the 
CAI(^.  The  POE.  CCA  and  Service  Cost  Position  (SCP)  estimates  and  the  groundailes  and 
assumptions  used  should  be  consistent  with  the  COEA  estimate. 
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1.  ELEMENT:  D3.  TBS  0.1. 3.0  IFC  93-3 

2.  ELEMENT  TITLE:  Establish  Industry  Link(s)(As  Required) 

3.  ELEMENT  OWNER(S):  Operating  MAJCOM 

4.  ELEMENT  STAKEHOLOER(S):  Product  Centers.  Labor^ories,  and  Industry 

5.  REQUIREMENT:  Department  of  Defense  Instruction  5000.2,  Defense  Acquisition  Management 
Policies  and  Procedures.  23  Feb  91 .  Part  5,  Section  A.  paragraph  3c;  Section  E;  Part  10,  S^bn  C, 
paragraph  2e.  Early  industry  involvement  in  the  acquisition  eff^  shaH  be  encouraged  to  take  advantage 
of  industry  expertise  to  improve  the  acquisition  strategy. 

6.  PURPOSE/OBJECTIVES:  The  purpose  of  establishing  an  early  link  with  industry  is  to  obtain  the 
latest  technological  information  in  support  of  Air  Force  deficiencies.  Participation  in  early  study  or 
mission  needs  efforts  will  allow  industry  visibility  into  potentisd  requests  for  acquisition  support.  The 
objectives  for  this  block  are  as  follows:  (a)  to  establish  an  open  communications  link  between  the  Air 
Force  and  potential  defense  contractors  ,  (b)  to  provide  the  latest  requirements  information  to  potential 
defense  contractors,  and  (c)  to  obtain  information  from  Defense  Contractors  on  the  latest  technologicai 
developments. 

7.  DESCRIPTION: 

a.  This  particular  block  is  not  directed  by  a  regulation.  It  is  an  activity  that  must  be  ongoing 
throughout  the  whole  Program  Development  Process.  This  activity  pertains  to  contacts  and/or  formal 
contractual  arrangements  with  our  customers/partners  in  irxfustry  who  are  considered  an  integral  part  of 
the  process.  It  is  a  matter  of  good  business  practices  and  the  establishment  of  effective  ongoing 
communications.  In  the  predecessor  Block  C4  (Review  Mission  and  Area  Plans),  it  is  important  that 
industry  be  brought  in  early  to  help  establish  the  initial  link  between  potential  suppliers  and  the  users. 

This  may  save  a  lot  confusion  downstream.  This  block  ties  into  successor  block  D29  (Industry  Monitor 
and/or  Participate  in  Government  Programs  through  IR&D,  RFIs,  RFPs,  and/or  Other  Means).  D29 
summarizes  all  of  the  predecessor  blocks  which  tie  into  it. 

b.  Obtainir^  early  industry  involvement  is  vital  to  the  long  term  success  of  the  acquisition.  Early, 
open,  and  effective  communications  may  result  in  efficiently  tailored  and  documented  requirements, 
b^er  focused  technology  development,  as  well  as  fewer  a^ersarial  relationships.  The  operating 
MAJCOM  and  Project  Manager  should  decide  the  level  of  industry  involvement  needed  and  coordinate 
their  thinking  with  the  Procuring  Contractirig  Officer  (PCO).  Information  corx^eming  the  acquisition 
should  be  provided  to  all  interested  potential  offerors  so  that  no  company  receives  an  unfair  competitive 
advantage. 

c.  The  operating  MAJCOM  is  the  responsible  authority  in  establishing  industry  links.  They  will  be 
responsible  in  providing  furKfing,  if  applicable,  to  support  this  effort.  In  rrost  cases,  the  operating 
MAJCOM  should  depend  upon  the  acquisition  expertise  available  within  AFMC  to  actually  initiate  this 
effort. 

d.  In  previous  years,  because  of  the  gerterally  adversarial  relationship  between  government  and 
industry,  acquisition  strategies  and  documents  were  developed  and  prepared  solely  by  government 
personnel.  They  were  based  almost  exclusively  on  information  generated  either  within  the  Gfovemment 
or  through  Requests  for  Information  to  industry.  Industry  particfoation  was  thus  limited,  and  participants 
were  often  left  in  the  dark  wondering  what  happened  to  their  comments. 

e.  The  lack  of  effective  communication  in  the  past  created  misunderstandings  and  frequently 
caused  companies  to  waste  resources  on  inappropriate  design  or  development  activities.  To  establish 
govemment/industry  relationships,  the  following  communication  methods  can  be  used  throughout  the 
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earty  industry  invoivement  process.  Methods  selected  wiU  be  dependent  on  specific  objectives  for  each 
given  effort.  Not  aH  options  are  appropriate  in  every  case. 

1.  Establish  a  Technical  Libran^.  This  is  a  central  location  where  key  releasable  documents  are 
made  available  for  potential  offeror's  review.  The  Project  Manager  authorizes  the  use  of  a  program 
technical  library  and  determines  which  information  and  at  what  stage  of  development  will  be  provided  in 
the  library.  The  PCO  or  Project  Manager  oversees  the  operation  of  the  library,  publicizes  its  existence, 
receives,  evaluates,  arxf  disposes  of  all  questions  or  comments  generated.  Once  established,  the 
location  must  be  publicized  by  a  notice  in  the  Commerce  Business  Daily.  Every  effort  should  be  made  to 
ensure  that  all  potential  offerors  have  ec^al  and  open  access  to  the  information  contained  in  the  library. 

2.  Conduct  a  Pre  solicitation  Conference  with  Industry.  This  is  an  excellent  method  of 
conveying  information,  enhancing  understanding  of  the  requirement,  reducing  adversarial  relationships 
and  building  a  sense  of  ownership  in  the  program  from  both  the  Government  and  industry  standpoint. 
Iixfustry  conferences  must  be  published  in  the  Commerce  Business  Daily  to  facilitate  wide  industry 
participation. 

3.  Establish  or  Make  Wider  Use  of  an  Electronic  Bulletin  Board.  This  is  a  database  that  can  be 
accessed  by  industry  utilizing  standard  modems  over  common  carrier  telephone  lines.  The  project 
manager  authorizes  the  use  of  these  bulletins  boards  for  program  specific  information  and  identifies 
carKfkfate  documents  or  information  for  inclusion.  Dependir^g  on  phase  of  competition,  the  Competkion 
Advocate's  office  may  need  to  be  involved  to  foster  increased  responsiveness  and  competitbn. 


4.  Utilize  the  Ombudsman  Program.  Each  product  center  has  established  an  ombudsntan  to 
serve  as  a  channel  for  irxfustry  comments  on  a  non  attribution  basis.  The  ombudsman  should  be 
identified  in  each  of  the  above  methods  of  communication. 

5.  Establish  Communication  Link.  Hold  periodic  meetings  weekly,  monthly,  or  as  required  with 
local  representatives  of  the  companies  with  an  interest  in  the  project  activities.  These  provide  an 
organized  forum  for  passing  information  and  assure  that  each  company  involved  has  the  opportunity  to 
receive  the  same  informatbn. 

6.  Visits  to  Industry.  If  practical,  make  one  or  two  visits  per  year  to  each  company  to  discuss 
project  activities  and  share  information.  This  activity  will  be  highly  dependent  on  the  number  of  offerors 
and  the  availability  of  government  travel  funds.  These  visits  albw  the  company  an  opportunity  for  a 
relatively  large  audience,  compared  to  the  number  that  would  travel  to  the  government  bcatbn,  to  listen 
to  the  most  current  information  updates  and  ask  questions. 
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When  informatbn  necessary  from  potential  sources  cannot  be  obtained  by  more  ecoix>mical  and  less 
formal  means,  the  Contracting  Offber,  with  approval  from  a  level  above  the  CO.  may  issue  an  RFI.  This 
type  of  announcement  provides  a  broad  statement  of  need,  briefly  describes  the  Government's  intentions 
regarding  program/acquisitbn  approach,  and  identifies  key  events.  In  addition,  the  announcement 
requests  industry  comments  on  how  the  Government  can  satisfy  its  needs,  alternative  approaches, 
technology  availability  and  risk,  the  bentificatbn  of  cost,  drivers,  and  suggestions  on  ways  to  enhance  or 
sustain  competitbn.  The  request  shall  cite  the  provision  at  FAR  52.215-3,  "Solbitatbn  for  Informatbn 
and  Planning  Purposes.*  All  resporbents  to  this  notbe  shall  be  included  on  the  Source  List,  unless 
specifbally  decliried  by  the  firm.  As  stated  above,  the  government  should  not  just  automatically  issue  an 
RFI.  Some  companies  spent  milibns  of  dollars  resporbing  depending  on  the  subject.  Many  companbs 
will  feel  obligated  to  respond  just  to  stay  competitive.  It  is  an  optbn  but  coub  be  costly  to  industry.  For 
more  information  regarding  RFI,  reference  Air  Force  System  Command  Request  for  Proposal  Process 
Gube,  Module  2.2. 

f .  Bulbing  a  partnership  with  irbustry  is  critical,  since  they  are  an  additional  source  of  expertise  to 
ensure  the  correct  definitbn  of  the  defbiency  (unfulfilled  missbn  need)  and  the  best  approaches  to 
resolving  it.  Once  a  deficiency  has  been  bentified,  it  behooves  the  government  to  have  industry  aware 
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of  the  deficiency  and  establish  a  link  tor  potential  business.  During  the  Preconcept  Phase,  the  key  to 
additional  pursuits  with  industry  is  predicated  upon  available  fundiito-  If  funds  are  available,  industry 
may  be  requested  to  provide  studies  with  regard  to  the  deficiencies.  The  avaUabUity  of  tonding  at  this 
stage  could  cause  serious  limitations  to  a  program.  The  degree  of  their  participation  is,  of  course,  limited 
by  the  rules  of  information  releasability,  the  Competition  in  Contracting  Act,  and  good  business  practices. 
While  irtoustry  participation  is  encouraged,  the  Government  must  treat  all  potential  offerors  fairly  and 
ensure  that  no  offeror  is  afforded  a  competitive  advantage  as  a  result  of  government  actions.  The 
following  are  contractual  ways  to  obtain  additional  information  from  industry: 

1.  Task  order  contract.  Laboratory  and  development  planning  support  may  be  obtained  by  use 
of  contracts  utilizing  task  ordering  arrangements.  Task  ordering  arrangernents  are  appropriate  tor  those 
instances  in  which  a  defined  need  exists  tor  contractual  support  of  the  scientific  and  technical  mission, 
the  precise  nature,  quantity  or  schedule  of  the  effort  requirement  cannot  be  precisely  determined  in 
advance,  but  tor  which  the  description/specifications/work  statement  can  be  defined  in  general  terms. 
Contract  requirements  and  specifications  shall  be  written  as  definitively  as  possible  from  the  onset,  but 
not  tailored  to  any  particular  approach.  For  more  detail  regarding  task  order  arrangements,  reference 
PMR  Management  Instruction  70-75.  Being  able  to  add  to  an  ongoing  task  order  contractual 
arrangement  is  probably  the  most  expeditious  means  in  getting  a  study  generated  and  should  only  take  1 
to  2  months  from  identification  of  a  deficiency  to  generating  a  study  request. 

2.  Request  for  Proposal  IRFPL  If  an  existing  task  order  contract  is  not  available,  then  a  RFP 
may  be  required  and  is  announced  in  the  Commerce  Business  Daily.  The  Commerce  Business  Daily  is 
industry's  link  with  the  government  for  upcoming  activities.  The  formal  RFP  system  will  apply  (reference 
D64.  Prepare  Request  for  Proposal).  During  the  pre-Concept  phase,  a  new  RFP  may  not  te  the  usual 
means  to  initiate  the  procurement  of  study  efforts  if  the  project  office  can  locate  an  existing  task  order 
contract.  The  RFP  is  a  vehicle  available  to  the  operating  MAJCOM  if  a  funding  source  is  availabie. 

3.  Broad  Agency  Announcement  fBAA^  BAA(s)  are  a  method  of  soliciting  and  contracting  tor 
R  &  D  efforts  which  are  considered  areas  of  interest  that  are  broad  in  scope  and  iTx>re  topical  in  nature. 
The  synopsis  in  the  Commerce  Business  Daily  serves  as  the  RFP  and  sets  forth  the  areas  of  exploration 
(statement  of  work)  arrd  the  award  criteria.  The  BAA  may  be  used  by  agencies  to  fulfill  their 
requirements  tor  scientific  study  and  experimentation  directed  toward  advancing  the  state  of  the  art  or 
increasing  knowledge  or  understanding  rather  than  focusing  on  a  specific  system  or  hardware  solution. 
This  technique  shall  only  be  used  when  meaningful  proposals  with  varying  technical/scientific 
approaches  can  be  reasonably  anticipated.  The  availability  of  the  BAA  shall  be  published  in  the 
Commerce  Business  Daily  and  may  be  published  in  noted  scientific,  technical,  or  engineering 
periodicals.  Proposals  received  as  a  result  of  the  broad  agency  announcement  shall  be  evaluated  in 
accordance  with  evaluation  criteria  specified  through  a  peer  or  scientific  review  process  (project  engineer 
or  program  manager).  The  primary  basis  for  selecting  proposals  for  acceptance  shall  be  technical 
soundness,  importance  to  agency  programs,  and  fund  availability.  Cost  realism  and  reasonableness 
shall  also  be  considered  to  the  extent  appropriate.  For  more  information  regarding  broad  agency 
announcement  reference  AFMCFARS  5M5.016. 

4.  Program  Research  and  Develooment  Announcements  (PRDA).  The  PRDA  is  an 
announcement  in  the  Commerce  Business  Daily  of  a  requiring  activity's  interest  in  new  and  creative 
research  or  devetopment  solutions  to  scientific  or  engineering  problems,  with  the  intent  to  solicit 
proposals.  This  announcement  may  appropriate  for  exploratory  research  that  has  general  application 
and  is  not  system  specific,  i.e.,  not  related  to  the  devel^ment  of  a  specific  weapon  system  or  a  specific 
hardware  development  effort.  Program  research  and  devetopment  announcements  are  used  when  use 
of  a  conventional  statement  of  work  could  result  in  unintentional  stifling  of  new  and  creative  solutions 
through  any  of  the  research  and  development  approaches.  This  announcement  maximizes  competition 
in  the  same  manner  as  broad  agency  announcement.  For  additional  information,  reference  AFMCFARS 
5335.90. 
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8.  ENTRANCE/emr  CRITERIA: 

a.  Entrance:  Determination  of  a  potential  or  establishnient  of  a  formal  government  effort  to 
investigate  a  m»sion  area  for  potential  deficiencies. 

b.  Exit:  Efforts  continue  until  project  or  study  effort  is  terminated. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  Mission  Area  Assessment  (MAA)  (Cl). 

(2)  Mission  Need  Analysis  (MNA)  (C3). 

(3)  Defense  Planning  Guide  (National  Defense  Planning,  At). 

(4)  Air  Force  Defense  Planning  (B-1). 

The  above  inputs  are  needed  to  establish  the  requirements  for  the  project. 

b.  Outputs:  Meetings,  bulletin  board,  Knks,  visits.  Requests  for  Information,  contracting  vehicles 
(i.e.,  task  order.  Request  for  Proposal.  Broad  Agency  Announcement  or  Program  Research  and 
Development  Announcement),  and  etc. 

10.  KEY  REFERENCES: 

a.  Department  of  Defense  Instruction  5000.2,  Defense  A^isition  Management  Policies  and 
Procedures,  23  Feb  91 ,  Part  5,  Section  A,  paragraph  3c;  Section  E;  Part  10,  Section  C,  paragraph  2e. 

b.  ASAF(a)  Acquisition  Policy  Letter  91 M-001 ,  dated  20  Jun.  91 . 

C.  AFMCFARS  5315.405-90(d)(2).  Pre-DrafI  RFP  Activfties. 

d.  FAR  6.102(D)(2)Broad  Ageiicy  Announcement  (BAA). 

e.  DFARS  235.01 6,  Broad  Agency  Announcement  (BAA). 

f.  AFMCFARS  5335.016,  Broad  Agency  Announcement  (BAA). 

g.  AFMCFARS  5335.90,  Program  Research  and  Development  Announcements  (PRDA). 

h.  PMR  Management  Instruction  70-75,  Task  Order  Arrangements,  24  Nov  89. 

i.  Dept,  of  the  Air  Force  Ltr,  Acquisition  Policy  91  M-001 ,  20  Jun  91 . 

11.  IMPLEMENTATION  TOOLS: 

a.  AFSC  Request  for  Proposal  Process  Guide,  Jan  92 

b.  Electronic  Bulletin  Boards  -  electronic  capabilities  accessble  by  industry  over  common  telephone 
lines,  modem,  and  IBM  compatible  computer  can  be  used  to  index  library  information,  upload  essential 
documents  or  provide  information  in  an  expeditious  manner.  AFMC  has  established  su^  a  link  called 
Helpful  Information  for  Industry  (HIFI)  which  identifies  currertt  arfo  planned  acquisition  activities.  In 
addition,  the  F-22  and  B-2  Systems  Program  Offices  have  established  bulletin  board  links.  ASC/CYX 
also  has  a  bulletin  board  for  all  ASC  RFP  and  Source  Selection  teams  to  use. 

c.  Standardize  Document  5,  Market  Analysis  for  Non-Oevelopmental  Items,  -  this  describes  ways  to 
accomplish  a  market  survey.  It  is  designed  to  avoid  distinguishing  between  a  commercial  or  a  military 
application.  Contact  the  Office  of  the  Assistant  Secretary  of  Defense  (Production  and  Logistics). 

d.  Information  Analysis  Centers  (lACs)  -  Catalogs  which  identify  study  and  analysis  activities 
conducted  by  contractors  covering  a  wide  range  of  technical  subjects.  May  assist  the  project  manager  in 
the  identification  of  potential  sources.  Contact  WL/FIVS/SURVIAC. 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  duration  to  initiate  an  industry  link  is  dependent  upon  user's  schedules,  funding, 
and  the  contracting  action  taken  to  implement  industrial  studies.  If  a  task  order  contract  already  exists, 
the  effort  can  take  from  1  to  2  months  to  place  on  contract.  If  a  formal  Request  for  Proposal  is  required, 
the  effort  can  take  3  to  9  months  depending  upon  the  number  of  draft  Request  for  Proposal  iterations. 
Once  initiated,  duration  may  continue  for  years  until  project  terminates. 

b.  CONSTRAINTS:  Availability  of  adequate  funding,  time  and  schedules.  Security  restrictions 
would  also  have  to  be  considered  if  an  effort  is  involved  with  classified  or  special  access  information. 

c.  RESOURCES:  Procuring  Contracting  Officer  (1).  Contract  Negotiator  (1).  Project  Engineer  (1). 
Financial  Manager  (1).  and  Project  Management  (1). 

d.  LESSONS  LEARNED:  Future  program  success  is  dependent  on  good  govemment/industry  team 
work;  poor  coordination  could  easily  lead  to  lack  of  understanding,  schedule  slips,  and  cost  overruns. 

e.  BEST  PRACTICES:  A  blanket  Notice  of  Corrtract  Action  is  published  semiannually  to  provide 
earliest  possible  notice  to  industry  of  planned  acquisitions.  By  identifying  all  planned  activity  for  a  6- 
month  period,  industry  is  provided  the  opportunity  to  form  teaming  arrangements  or  to  improve  business 
decisions  in  the  use  of  limited  resources.  In  the  early  inception  of  a  program,  hold  monthly  brown  bag 
lunches  with  prospective  contractors  to  get  their  early  inputs  into  the  program.  Also,  it  may  be  berreficial 
to  have  a  meeting  after  issuance  of  an  RFI,  where  all  respondents  can  come  to  ask  questions. 

f.  TRAPS:  Limiting  participation  to  only  large  contractors  and  not  reviewing  all  potential  offerors 
available.  Even  though  new  technological  advancements  are  usually  found  in  large  Research  and 
Development  organizations,  the  government  should  make  all  efforts  not  to  exclude  anyone.  All  offerors 
need  to  be  given  an  equal  opportunity.  Care  must  be  taken  to  ensure  that  no  company  is  given  an 
unfair  advantage  (e.g.,  receiving  information  that  is  not  available  to  all  companies).  If  this  were  to 
happen,  a  protest  could  delay  the  program  for  many  months.  When  using  noncontractual  type  vehicles, 
caution  must  be  used  to  ensure  that  if  there  is  a  need  to  make  the  information  and  commitments  of  a 
contractor  or  offeror  binding,  the  commitments  must  be  reflected  in  a  resultant  contract. 
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1.  ELEMENT:  D4,  TBS  0.1 .7.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Conduct  Deficiency  Analyses  Support  (As  Required) 

3.  ELEMENT  OWNER(S):  Operating  Command.  Product  Center  XRs 
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4.  ELEMENT  STAKEHOLOER(S):  Air  Force  Materiel  Command  (AFMC),  Aeronautical  Systems  Center 
(ASC),  Air  Force  Acquisition  Model  (AFAM)  office.  Product  Center  XRs.  ASC/YX.  Industry,  Laboratories. 

5.  REQUIREMENT: 

a.  Air  Force  Policy  Directive  10-6. 19  Jan  93;  Air  Force  Instmction  (AFI)  10-601 ,  Mission  Needs 
and  Operational  Requirements  Guidance  and  Procedures.  16  Jan  93,  Pages  2-3. 

b.  DoDI  5000.2,  Defense  Acquisition  Directive,  Part  4,  Section  B. 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose:  The  product  center  XRs  are  the  principle  sources  of  support  to  the  operating 
commands  for  conducting  deficiency  analyses.  The  purpose  of  this  element  is  to  describe  that  support 
function  and  explore  the  details  of  the  campaign  level  analyses  conducted  in  support  of  the  operational 
command. 

b.  Objectives;  The  objectives  of  this  activity  are  the  same  as  described  in  C6  and  include 
providing  a  campaign  level  analysis  of  the  defined  forces,  evaluating  their  ability  to  accomplish  theater 
objectives,  and  identifying  any  deficiencies  that  are  found.  This  activity  is  conducted  in  response  to  a 
request  tor  support  from  the  operational  command  (C6). 

7.  DESCRIPTION: 

a.  The  Mission  Needs  Analysis  (MNA)  process  addresses  the  missions  and  tasks  which  have 
been  identified  during  the  Mission  Area  Analysis  (MAA).  The  focus  of  the  MNA  is  on  assessing  the 
capabilities  of  current  and  programmed  forces  to  conduct  operations  achieve  the  goals  (missions  and 
ta^s)  and  consequently  overcome  the  identified  threat  (B2)  (established  in  the  regional  scenarios 
defined  in  the  MAA,  Cl )  and  identify  operational  shortfalls  arid  needs.  The  deficiency  analysis  employs 
a  task-to-need  evaluation  process  to  identify  operational  shortfalls  (deficiencies)  in  the  current  and 
programmed  forces  and  force  structures.  Campaign  analyses  are  the  principle  tool  used  to  accomplish 
these  task-to-need  assessments. 

b.  In  order  to  accomplish  deficiency  analyses,  quantitative  information  on  force  stmctures,  force 
locations,  force  element  capabilities,  concepts  of  operations,  geography,  environment  and  target,  must 
be  developed  for  both  sides  in  the  conflict.  Warning  time,  deployment  decision  time,  and  start  of  conflict 
information  for  other  services  and  allied  forces  must  also  be  defined.  The  critical  parameters  identified 
as  a  part  of  the  deficiency  analyses  are  Measures  of  Merit  (MOMs  ),  Measures  of  Performance  (MOPs) 
and  Measures  of  Effectiveness  (MOEs)  that  allow  conclusions  to  be  drawn  regarding  the  success  of 
campaigns. 

c.  Deficiency  analyses  are  conducted  at  the  campaign  level  using  models  that  simulate  and 
quantify  predetermined  critical  parameters  of  mock  engagements.  These  modeled  engagements  reflect 
the  DPG/AFPG  strategies  and  MAA  identified  missions,  tasks  and  force  interactions  in  theater. 
Performance  (our  ability  to  achieve  identified  tasks  and  accomplish  required  missions)  is  predicated  on 
an  evaluation  of  the  simulation  results  against  the  predetermined  metrics.  Failure  to  meet  operational 
objectives  (missions/tasks)  is  an  indication  of  potential  deficiencies  (operational  shortfalls).  These 
metrics  establish  whether  deficiencies  in  force  structure  or  operations  may  exist.  The  results  of 
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deficiency  analyses  are  provided  at  a  very  high  level,  (i.e.  whether  or  rKM  the  total  forces  can  accomplish 
the  tasks).  The  emphasis  is  on  identifying  deficiencies,  not  solutions.  As  required.  foUow-on  analyses 
will  be  conducted  £is  a  part  of  C7  and  D7,  k>  establish  whether  nonmateriel  characteristics  of  the 
campaigns  can  be  altered  to  achieve  the  desired  outcomes  (accomplish  the  tasks).  TNs  activity 
provides  source  data  for  accomplishing  follow-on  alternative  materiel  solutions  analyses. 

8.  ENTRANCE/EXIT  CRITERIA:  This  activity  begins  when  the  operating  conwnand  requests  support  to 
evaluate  US  ability  to  accomplish  defined  missions  and  tasks.  It  is  complete  when  the  operational 
shortfalls  are  assessed  to  the  satisfaction  of  the  operating  command. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1 )  Concept  of  Operations  (C2 ). 

(2)  Mission  definition  (tasks)  and  force  projections  (C1 ). 

(3)  Threat  information  (B2). 


b.  Outputs;  The  results  of  campaign  analyses  are  documented  in  an  Operational  Shortfalls 
(Deficiencies)  Report  and  provided  to  the  Operating  Command  (C6).  and  source  data  are  provided  to 
support  activities  in  07.  Outputs  include: 

(1)  Description  of  scenarios. 

(2)  Assumptions  and  constraints. 

(3)  Potential  Deficiencies. 

10.  KEY  REFERENCES:  Air  Force  Instruction  1 0-601 ,  Mission  Needs  and  Operational  Requirements 
Guidance  and  Procedures,  dated  16  Feb  93. 

11 .  IMPLEMENTATION  TOOLS:  The  campaign  level  deficiency  analyses  are  perfonned  using  models 
that  describe  the  interaction  of  forces  at  the  campaign  level,  comparing  the  quantified  parameters 
(identified  in  Para.  7,  above)  with  predetermined  measures  of  merit  for  mock  engagements.  The  results 
indicate  potential  deficiencies,  not  solutions. 

12.  PLANNING  GUIDANCE:  Prior  to  proceeding  into  the  deficiency  analyses,  the  supporting  analysts, 
designers  and  logisticians  must  be  provided  an  opportunity  to  become  familiar  with  the  output  of  the 
MAA  (if  they  did  not  support  that  activity)  and  adapt  analytical  tools  to  operational  concepts,  force 
structures,  and  campaign  scenarios.  The  strategic  information  documented  in  the  DPG  and  the  tasks 
identified  in  the  specific  mission  area  must  be  made  available  to  the  performing  activity  to  ensure  that  a 
thorough  evaluation  is  conducted  and  proper  constraints  and  assumptions  are  applied. 

a.  DURATION:  It  typically  takes  a  minimum  of  6  months  to  conduct  a  campaign  level 
deficiency  analysis.  For  complex  study  efforts  (missions  and  tasks  involving  the  interaction  of  multiple 
systems)  the  deficiency  analysis  may  fake  a  year  or  more. 

b.  CONSTRAINTS:  The  scenarios  should  conform  to  the  Defense  Planning  Guidance  (DPG), 
addressing  all  assumptions  made  regarding  the  threat  and  US  and  allied  involvement  (mix).  All  relevant 
situations  in  the  DPG  scenarios  should  be  addressed  in  the  analysis.  US  force  availability  should  be 
consistent  with  any  deployment  or  reinforcement  objectives  included  in  the  scenarios  and  established  in 
the  DPG. 

c.  RESOURCES:  Resource  allocation  is  left  as  an  issue  for  the  specific  acquisition  activity. 
Typically,  the  team  assigned  to  conduct  a  campaign  level  deficiency  analysis  would  include  functions 
covering  mission  analysis,  design  engineering  (including  software),  logistics  (supportability. 
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deployability,  maintainability,  operability),  cost,  contracting  and  management.  Data  produced  in  the 
course  of  conducting  the  d^iency  analyses  is  used  across  all  functions  to  support  ongo^  sensitivfty 
and  effectiveness  analyses. 

d.  LESSONS  LEARNED:  The  Air  Force  Lessons  Learned  Program  should  be  consulted  for 
current  lessons  learned  regarding  conducting  campaign  level  deficiency  analyses. 

e.  BEST  PRACTICES:  It  is  essential  that  the  operating  command  participate  in  this  effort  to 
verify  that  the  concepts  of  operations  are  realistic  and  that  any  identified  deficiencies  are  described 
adequately  to  support  follow-on  evaluation  of  nonmateriet  soMions  (C7  arxf  D7). 

f.  TRAPS:  The  results  of  any  campaign  simulation  are  very  dependent  upon  assumptions 
regarding  the  way  the  forces  are  alkx^ed  in  accordance  with  the  initial  strategy  and  the  response  to  the 
situatbn  as  it  evolves.  All  assumptions  made  in  support  of  performing  the  campaign  level  deficiency 
analyses  must  be  clearly  identified  and  sensitivity  analyses  on  their  impact  on  the  results  must  be 
conducted. 
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1.  ELEMEIIT:  DOS.  TBS  0.1 .8.0  (IFC93-3) 

2.  ELEMENT  TITLE:  Assess  Technology  Areas 

3.  ELEMENT  OWNER(S):  Technical  Plarming  Integrated  Product  Teams  (TPIPTs). 

ASC/XR 

4.  ELEMENT  STAKEHOLDER(S): 

a.  Operating  commands 

b.  Irnplementing  commands 

c.  ASC/XR 

d.  ASC/YX 

e.  System  program  offices 

i.  Wright  Laboratory  (WL.) 

j.  Armstrong  Laboratory 

k.  Other  USAF.  U.S.  Military  ,  and  OOD 
laboratories 

l.  Product  center  development  planning  organcrations  and  program  offices 

m.  Logistics  centers. 

5.  REQUIREMENT:  DODI  5000.2.  Defense  Acquisition  Management  Policies  and  Procedures.  23 
February  1991 

a.  Part  5.  Acouisttion  Strategy.  Section  D.  TechnoloQv  Transition  and  Prototvoino.  This 
requirement  directs  that  the  acquisition  strategy  for  defense  acquisition  programs  identify  plans, 
activities,  and  criteria  for  assessing  and  transitioning  critical  technologies  from  technolo^  development 
and  demonstration  programs.  Section  D  establishes  the  policies  and  procedures  to  be  followed  to 
accomplish  this  requirement. 

b.  Part  6.  Enoineerino  and  Manufacturing.  Section  A.  Systems  EnQineerino.  This  requirement 
establishes  the  systems  engineering  policies  and  procedures  to  be  followed  for  technology  transition 
efforts. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  Identifiy  and  evaluate  technologies  that  are  under  development  at  U.S. 
Government  laboratories  and  in  industry. 

b.  Objectives; 

(1 )  Identify  technologies  with  potential  application  to  meeting  requirements  of  user 
mission  area  plans  (C4). 

(2)  Perform  preliminary  evaluation  of  relevance  and  utility  of  technology  programs. 

(3)  Enhance  user  understanding  and  support  of  emerging  technologies  and  concepts. 

(4)  Improve  the  quality  and  relevance  of  technology  development  to  user  requirements 
by  influencing  science  and  technology  investments  within  DoD  (D30)  and  in  industry  (D29). 
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7.  DESCfHFTION: 

a.  What  is  Tachnology  Area  Assessment? 

(1)  Technology  Area  Assessment  is  the  process  of  preliminary  identification  and 
evaluation  of  technology  development  programs  having  t^erttial  application  to  the  subject  mission  area. 
Technology  development  programs  can  include  those  bee^  performed  by  USAF  and  other  U.S. 
Government  laboratories  (Block  030)  and  by  industry  (Block  029). 

(2)  Although  Technology  Area  Assessmem  is  identified  as  an  early  st^  in  the  Pre- 
Milestone  0  phase  weapon  system  ac^isition,  it  is  actually  an  on-going  process  as  tong  as  weapon 
system  development  and  upgrade  actions  continue. 

b.  Who  does  Technology  Assessment? 

Technology  assessment  has  typically  been  accomplished  by  several  different 
organizations,  often  resulting  in  duplication  of  effort.  Organizations  performing  technology  assessments 
include  the  operating  commands,  product  center  development  planning  (XR)  organizations,  system 
program  offices  (including  ASC/YX),  etc.  Technology  assessment  is  also  one  of  several  activities  of 
product  center  chartered  Technical  Planning  Integrated  Products  Teams  (TPIPTs).  TPIPT  membership 
includes  representatives  of  alt  the  stakeholders  involved  in  technology-related  planning  for  specific 
mission  or  functional  areas.  As  Integrated  Weapon  Systems  Management  matures  in  USAF  weapons 
system  acquistion,  TPIPTs  should  become  the  single  technology  assessment  focal  point.  (Additional 
information  on  the  TPIPT  process  can  be  found  in  C4  and  018.  Also,  contact  ASC/XRS  and  HQ 
AFMC/XRX  for  current  guidance  on  the  TPIPT  process.) 

c.  How  are  technology  programs  identified? 

(1 )  Identifying  appropriate  technology  programs  can  be  a  function  of  the  reviewer's 
personal  awareness  of  technical  developments  in  his  own  area  of  expertise.  For  example,  personal 
awareness  can  result  from  working  relationships  with  laboratory  personnel  and/or  regular  reading  of 
technical  perMicals,  professional  journals,  etc..  This  is  a  very  useful  approach  but  is  inherently  limited 
in  scope.  Being  aware  of  technology  development  with  application  to  your  project  or  program,  you  can 
pursue  obtaining  detailed  information  through  personal  contacts  or  through  one  or  more  of  the  means 
described  in  the  paragraphs  below. 

(2)  Contact  your  product  center  development  planning  organization  (XR)  to  determine  if 
a  TPIPT  exists  for  the  mission  or  functional  area  of  concern.  The  TPIPT  chairman  or  an  XR 
represerrtative  should  be  aware  of  a  broad  scope  of  applicable  technology  development  programs 
underway  or  planned. 

(3)  U.S.  Government  Laboratory  Programs 

(a)  Information  on  laboratory  development  programs  can  be  obtained  by 
reviewing  technical  program  plans  published  by  U.S.  Government  laboratories.  For  example,  Wright 
Laboratories  (WL)  publishes  Technical  Area  Plans  (TAPs)  which  identify  specific  technology  program 
thnjsts  and  associated  technology  developments  in  USAF  or  Joint  Service  Programs.  Included  in  the 
TAPs  is  a  description  of  how  the  technologies  are  related  to  each  other,  changes  from  the  previous  year, 
major  accomplishments,  expected  time  to  maturity,  and  technology  transition  plans.  WL  TAPs  can  be 
obtained  from  WL/XPT  or  Defense  Technical  Information  Center  (DTIC).  Technical  program  plans 
should  be  available  from  all  U.S.  Government  laboratories  either  directly  or  through  DTIC. 

(b)  More  specific  technology  program  information  may  be  obtained  by  attending 
laboratory  program  review  presentations  or  by  reviewing  lab  program  review  reports.  For  example, 
Wright  Lffooratory  conducts  an  annual  Spring  Program  Review  during  which  individual  technology 
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developmeiV  programs  are  described  in  a  series  of  detailed  briefings.  WL  also  publishes  an 
accompanying  report  which  contains  the  presentation  briefkig  charts.  The  WL  Spring  Program  Review 
report  can  be  obtained  from  WUOOX.  Contact  other  laboratory  program  planning  offices  for  availabilily 
of  program  reviews  and/or  reports. 

(4)  SPO-st»nsored  technoloQv  develooment  Product  center  system  program  offices 
(SPO)  can  directly  fund  laboratories  and/or  industry  to  develop  technology  for  specific  application  to  the 
SPO  product.  It  could  be  worthwhile  to  contact  SPOs  with  similar  missions  to  d^elop  weapon  systems 
and  supporting  technology.  For  instance,  technology  being  developed  for  the  B-2  or  F-22  could  have 
application  to  a  next  generation  muKi-role  fighter.  With  shrirtking  budgets  for  military  developmer4 
programs,  development  of  common  technologies  is  already  taking  place,  so  information  should  be 
eagerly  shared  b^een  program  offices.  (Note;  Technology  information  sharing  for  higMy  classified 
efforts  such  as  signature  reduction  may  be  more  difficult  to  obtain.)  When  seeking  information  from 
other  SPOs,  contact  the  engineering  or  program  management  directorates  of  those  organizations. 

(5)  Other  Service  programs.  Technology  sharing  between  developnrtent  programs  of 
other  services  is  also  becoming  more  common.  For  example,  common  avionics  nriodules  could  be 
developed  for  application  to  the  USAF  F-22  air  superiority  fighter,  U.S.  Army  LHX  helicopter,  and  the 
Navy/Marine  F/A-18E/F.  U.S.  Navy/Marine  Corps  and  Army  technology  development  may  have  direct 
application  to  yeur  USAF  programs.  Use  your  personal  contacts  or  contacts  in  the  laboratories  anti 
product  center  and  operating  command  development  plannirig  (XR)  organizations  to  help  you  find 
contacts  in  service  programs  you  need  information  from. 

(6)  Literature  Searches.  A  great  deal  of  technical  information  from  U.S.  and  foreign 
sources  is  available  as  published  literature  in  the  form  of  technical  reports,  professional  journals, 
periodicals,  books,  etc.  Using  key  words  or  phrases  associated  with  the  technology  or  mission  area  of 
interest,  computer  database  literature  searchs  can  be  performed  to  identify  available  published 
information.  One  such  database  is  maintained  by  the  Defense  Technical  Information  Center  (DTIC). 
Literature  search  services  are  available  to  assist  you  with  consulting  DTIC  and  other  information 
databases.  Contact  the  Wright  Laboratory  Technical  Library  at  Wright  Patterson  AFB  (DSN  785-7454) 
for  information  and  assistarK:e. 

(7)  Industnr  IR&D.  Commercial  industry  also  funds  and  performs  technology 
development  programs  in  order  to  maintain  competitive  advantage.  Corporations  often  seek  U.S. 
Government  participation  (primarily  funding)  of  these  efforts  .  If  a  corporation  believes  a  technology 
development  may  be  applicable  to  a  potential  government  program,  it  can  submit  information  desorbing 
the  effort  along  with  a  request  for  funds.  Krrown  as  Indepertdent  Research  and  Development  (IR&D), 
these  efforts  benefit  both  industry  and  the  government.  Although  the  company  retains  proprietary  rights 
to  the  technology,  the  government  benefits  through  awareness  and  the  ability  to  use  the  informatbn  for 
advanced  planning.  IR&D  program  briefings  are  presented  annually  to  various  DoD  organizations 
including  rep^s  which  are  distributed  for  review.  Government  reviewers  grade  the  projects  for 
relevance,  utility,  and  approach  and  make  recommendations  on  government  support.  IR&D  report 
details  include  the  scope  of  the  program,  technical  approach,  intended  applications,  schedule,  cost,  and 
principle  personnel  involved  in  managing  and  conducting  the  programs.  Attending  the  briefings  allows 
direct  interaction  with  industry  people  involved  with  the  projects.  Companies  may  be  wilting  to  provide 
additional  briefings  to  specific  program  offices  who  are  particuarty  interested  in  their  program.  (Contact 
the  Wright  Laboratory  Plans  and  Programs  Directorate.  WL/XP,  for  information  on  IR&D  projects  that 
may  apply  to  your  program.) 

(8)  Foreign  Aerospace  Science  and  Technokxiv  Center  (FASTCL  Obviously,  not  all 
technology  applicable  to  USAF  weapon  system  integration  is  developed  in  the  United  States.  However, 
information  on  foreign  technology  is  often  difficult  or  impossible  to  oMain  through  routine  channels.  The 
Foreign  Aerospace  Science  and  Technology  Center  (FASTC)  at  Wright  Patterson  AFB  (formerly  known 
as  Foreign  Technology  Division  or  FTD)  often  obtains  and  analyzes  information  on  science  and 
technology  associated  with  foreign  weapon  systems.  Contact  FASTC  Information  Research  Services 
(FASTC/DXLR),  DSN  787-2248  for  further  assistance. 
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(9)  Aaend  Technical  Conferences.  Conventions,  and  Symposkiim.  Examples  include 
the  Natiorud  Aerospace  Electronics  Convention  (NAECON)  held  annual^  in  Dayton.  ONo;  SAE 
Aerospace  conferences  held  annualy.  Symposium  on  Avi^ion  Psychology  held  bi-annuaNy  at  Ohio 
Stale  Universily  in  Columbus,  Ohio.  etc. 

d.  How  is  technology  assessment  aooorrplished? 

(1 )  Identify  technology  development  programs  that  have  application  to  the  mission  or 
functional  area  of  the  proj^. 

(2)  Obtain  detailed  information  on  the  teclmology  programs  from  the  appropriate 
sources  as  described  above. 

(3)  Have  people  in  your  project/program  with  appropriate  expertise  review  the 
information  to  determine  if  the  techriology  is  relevant  and  useful  to  meeting  projected  technical 
requirements.  The  TPIPTs  are  a  potentially  useful  source  for  this  type  of  activity. 

(4)  Ensure  that  operating  command  requirements  people  are  kept  informed  on  the 
details,  schedule,  and  cost  of  ap^icable  technology  programs. 

(5)  Maintain  awareness  or  contact  with  applicable  technology  programs. 

(6)  Project/program  offices  should  actively  support  technology  development  programs 
that  are  applicable  and  of  interest.  This  support  can  include,  but  is  not  limited  to,  the  following; 

(a)  Recommend  operating  command  support  of  both  laboratory  and  industry 

technology  programs. 

(b)  Recommend  U.S.  Government  funding  of  industry  IR&D. 

(c)  Provide  direct  funding,  if  available,  of  appropriate  technology  development 

programs. 

(d)  Continue  involvement  with  the  relevance,  scope,  technical  approach, 
schedule,  funding,  and  priority  of  technology  developmertt  programs  assessed  as  critical  to  your  mission 
or  functional  area  through  the  following  program  development  process  activities: 

(1 )  Establish  Industry  Links  (D3) 

(2)  Determine  Applicability  of  NDI  (D1 3  and  D27) 

(3)  Identify  Cooperative  Development  Opportunities  (D1 4  and  D28) 

(4)  Prepare  Techrtology  Guidance  (D1 8) 

(5)  Assess  Technology  Needs  (043) 

(6)  Develop  and  Update  Technical  Plans(D20B  and  D23) 

(7)  Conduct  Concept  Definition  for  Preferred  Alternatives  (D37B) 

(8)  Prepare  RFP  (D64) 

(9)  Release  RFP  (D69) 

(10)  Establish  System  Program  Office  (D76) 

(11)  Award  and  Issue  Contracts  (D74) 

8.  ENTRANCE/EXiT  CRITERIA: 

a.  Entrance:  Technology  Area  Assessment  should  begin  during  Mission  Area  Planning  (Review 
Mission  Area  Plans,  Block  C4).  Although  technology  assessment  is  an  on-going  process,  it  can  be 
broken  down  into  annual  segments  due  to  the  annual  nature  of  laboratory  and  IR&D  reviews. 


» 


«) 


4r; 


» 


» 


» 


I 


I 


» 


I 


D-268 


I 


H»wt3 


(Note;  Technology  Area  Assessment  for  tNs  phase  ot  a  progrsn  should  begin  as  a  preliminary  look  at 
technology  with  pMential  application  to  the  stA^ect  mission  area.  However,  technology  assessment 
should  continue  in  some  form,  and  at  various  levels  detail,  throughout  the  lito  of  a  weapon  system 
acquisition  program.) 

b.  Exit:  When  applicable  technology  programs  have  been  identified  and  evakMSed  with  respect 
to  potential  efforts. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  The  following  inputs  are  required  to  accomplish  Technology  Area  Assessment.  The 
inputs  are  requked  because  they  provide  information  on  a  broad  scope  of  technology  development 
programs  and  they  are  easily  obtained. 

(1)  Technology  Program  Reviews  (WL/XP). 

(2)  Technology  Plans  tor  Wright  Laboratory  (WL/XPR). 

(3)  Technology  Area  Plans  (WUXPT) 

(4)  IR&D  Annual  Program  Reviews  (WL/XPR) 

(5)  IR&O  Annual  Plans  and  Reports  (WL/XPR) 

(6)  Literature  Searches  (WL/DOC).  The  Wright  Laboratory  Technical  Library  would 
be  the  primary  facilitator  for  accomplishing  literature  searches.  WL-assisted  literature  searches  will  allow 
you  to  search  the  OTIC  and  other  information  databases  through  which  you  should  be  able  to  find 
information  on  technology  development  programs  of  OoO  laboratories  other  than  WL. 

(7)  Review  of  Mission  Area  Plans  (C4). 

b.  Outputs;  The  following  outputs  are  required  from  the  Technology  Area  Assessment  process. 
The  outputs  are  required  in  order  to  provide  formal  documentation  of  the  technology  programs  that  were 
evaluated. 
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(1)  Technology  Investment  Recommendation  Reports  (TIRR)  developed  by  TPIPTS  • 

and  provided  to  mission  area  planners  (C4)  and  laboratories  (D30). 

(2)  Mission  Area  Development  Plans  developed  by  TPIPTS  or  XR  organizatbns  and 
provided  to  mission  area  planners  (C4). 

(3)  IR&D  evaluations  to  industry  (D29).  % 

(4)  Briefings  to  mission  area  planners  (C4),  laboratories  (D30),  industry  (D29),  etc. 

10.  KEY  REFERENCES:  See  requirements  (paragraph  5.  "Requirement,"  above). 

11.  IMPLEMENTATION  TOOLS:  • 

a.  See  "How  Are  Technology  Programs  Identified?"  (paragraph  7.c,  above). 

b.  Technical  Library  Data  Bases  such  as  the  Defense  Technical  Information  Center  (DTIC). 

c.  Technology  Program  Reviews,  from  WL/XP,  other  Service,  DOD,  and  National  Laboratories 

d.  Technology  Investment  Plans  for  Wright  Laboratory  from  WL/XPR,and  other  Service,  DOD, 

and  National  Laboratories  ^ 

e.  Technology  Area  Plans  from  WL/XPT 

f.  Professional  Journals,  technical  periodicals,  conventions/conferences  and  their  proceedings. 
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g.  See  requiremems  (paragraph  5. 'Requirefnent.' above). 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  As  previously  stated,  technology  assessment  should  be  an  ongoing  activity 
throt^hout  the  Hie  of  a  program.  However,  the  dur^ion  of  Technology  Area  Assessment  in  support  of 
Mssion  Area  Planning  (C4)  can  be  broken  into  quantifiable  elements.  Based  upon  the  foNowing 
descriptions  of  the  elements  of  technology  assessment,  you  will  have  to  develop  your  own  estimate 
how  long  Technology  Area  Assessment  activities  may  take  considering  the  scope  of  your  program  and 
the  quantity  of  technology  development  programs  to  be  reviewed. 

(1)  Information  Gatherinp.  Identifying  appropriate  technology  developement  programs 
and  gathering  information  from  the  sources  described  above  will  usuaMy  occur  in  multiple  segments  over 
a  calendar  period  ranging  from  several  months  to  a  year,  depending  upon  the  tinwng  relationship 
between  the  start  of  your  program's  technology  assessment  effort  and  the  schedule  of  planned 
technology  program  reviews.  Individual  information  gathering  activities  can  range  in  duration  from  a  few 
hours  or  a  day  or  two,  up  to  1  -2  weeks.  Fotowing  are  some  examples  of  some  of  the  more  well  defined 
information  gathering  activities  you  may  participate  in. 

(a)  Laboratory  and  IR&D  program  reviews  are  generally  annual  activities. 
Laboratory  reviews,  such  as  the  Wright  Laboratory  Spring  Review,  are  usually  planned  to  occur  on 
during  the  same  calendar  period  each  year.  Industry  IR&D  reviews  are  planned  in  a  similar  manner. 
Contact  the  Wright  Laboratory  Plans  and  Programs  Directorate  (WL/XP,  DSN785-2532)  for  scheduling 
information  for  the  Spring  Review  and  IR&D  reviews.  The  19^  WL  Spring  Review  was  held  during  the 
first  week  of  May  and  lasted  five  days.  IR&D  reviews  may  be  spread  over  a  period  of  weeks,  but  held 
during  the  same  calendar  period  each  year.  Of  course,  the  plans  and  reports  associated  with  these 
reviews  can  be  obtained  at  any  time  for  review  and  evaluation.  Labs  and  contractors  may  also  provide 
presemations  specifically  for  your  program  if  requested. 

(b)  Literature  searches  may  be  scheduled  at  your  convenience.  Because  it 
sometimes  takes  awhile  tor  the  library  staff  to  get  to  your  request,  gain  access  to  databases,  or  get 
corr^ter  time,  literature  searches  can  range  in  duration  from  an  hour  or  so  to  several  days.  You  will 
need  to  be  present  at  the  beginning  of  the  IKerature  search  to  provide  key  words,  phrases,  and  subject 
areas  and  to  help  the  library  staff  understand  exactly  what  you're  looking  for.  However,  since  it  may  take 
a  period  of  hours  or  days  to  actually  do  the  search,  you  may  not  have  to  be  present  during  the  whole 
time.  The  library  will  call  you  back  to  let  you  know  your  search  information  is  available  for  pickup.  You 
can  also  stilt  do  your  own  literature  search  the  old  way  by  using  library  card/computer  catalogs. 

Obtaining  applicable  documentation  discovered  in  the  literature  search  may  take  a  period  of  days  or 
weeks  depending  upon  the  source. 

(2)  Evaluation.  Information  should  be  reviewed  and  evaluated  shortly  after  it  is 
obtained  while  details  are  fresh  in  the  minds  of  those  involved.  Evaluations  can  be  done  in  various 
group  settings  (such  as  TPIPT  meetings),  by  individuals,  or  a  combination  of  methods.  Reviews  by 
individuals  can  range  in  duration  from  a  few  hours  to  several  days  depending  upon  the  quantity  of 
information  to  be  reviewed.  Group  reviews  such  as  a  TPIPT  meetings  can  range  from  a  day  to  several 
days.  An  example  of  an  actual  Technology  Area  Assessment  was  performed  in  support  of  the  USAF 
Multirole  Forces  Project  (MRFP)  by  the  Program  Development  SPO  Engineering  Division  (ASC/YXE)  in 
June  1 993.  Out  of  the  200  or  so  techrralogy  development  programs  presented  at  the  WL  Spring 
Review,  approximately  70  were  identified  were  identified  as  being  ap^icable  to  the  MRFP.  Each  of  the 
70  programs  were  evaluated  and  scored  by  individual  engineers.  Composite  scores  were  com|;»led  for 
each  program  and  discussed  by  a  group  of  senior  engineers  who  established  the  final  scores.  This  effort 
lasted  a  total  of  approximately  three  weeks.  Individual  time  spent  ranged  from  1  -2  hours  to  2-3  days.with 
the  over  a  period  of  approximately 

(3)  Renoitinq.  Once  information  is  gathered  and  evaluated,  appropriate  assessment 
reports  must  be  prepared  and  submitted  to  the  mission  area  planners  (C4).  Various  reporting  formats 
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are  descrt)ed  m  paragraph  9.b,  above.  Preparation  of  individual  reports  or  briefings  can  range  in 
duration  from  several  days  to  weeks  depending  upon  the  scope  and  quanitity  of  information  covered. 
Formal  coordhation  of  reports  and  approval  of  briefings  can  add  more  days  or  weeks  to  the  reporting 
cycle.  The  results  of  the  MRFP  review  described  above  were  presented  in  briefing  form  to  Air  Combat 
Command.  This  particular  presentation  required  approxirrutteiy  2-4  days  to  prepare. 

b.  CONSTRAINTS: 

(1)  Maintaining  awareness  of  a  broad  scope  of  technology  development  efforts  across 
government  and  inrtostry,  nationally  and  internationally,  can  be  very  time  consuming. 

(2)  In  addition  to  being  time  consuming,  obtaining  complete  information  on  technology 
development  efforts  from  all  DoD  laboratories,  other  services,  industry,  and  foreign  sources  can  still  be 
difficult.  Information  on  "black  world"  program  technology(s)  develop^nt  is  not  available  within  the 
general  laboratory  community. 

c.  RESOURCES: 

(1)  A  particular  TPIPT  may  consist  of  10-20  members  representing  a  broad  scope  of 
applicable  technical  arid/or  operational  exertise  and  supplemented  with  technical  experts.  Technical 
representation  should  cover  the  fields  of  engineering  (airframe ,  avionics,  propulsion,  electrical,  human 
factors/crew  systems,  manufacturing,  support  equipment/diagnostics,  etc.)  and  logistics  (acquisition 
logistics  and  logistics  support).  Operational  representation  should  include  expertise  in  operations, 
maintenance,  and  support  of  weapons  systems  in  the  same  mission  area.  Approximately  10-15 
engineers  involved  in  the  June  1993  ASC/YXE  MRFP  technology  assessment  attended  the  WL  Spring 
Review.  Approximately  20-30  engineers  from  YXE,  other  SPOs.  and  ASC/EN  functional  organizations 
participated  in  the  evaluation  of  the  lab  programs. 

(2)  Rnancial  resources  to  fund  travel  for  TPIPT  members  to  attend  program  reviews, 
conferences,  conventions,  etc.,  visit  contractors,  and  to  purchase  conference  proceedings,  subscriptions 
to  technical  journals  and  periodicals,  etc. 

d.  LESSONS  LEARNED: 

(1 )  Specific  attention  must  be  given  to  the  coordination  of  Technology  Area 
Assessment  activities.  Due  to  the  number  of  organizations  (as  described  in  paragraph  7.b,  above)  who 
can  do  technology  assessments,  coordination  efforts  should  be  focused  on  avoiding  duplication  of  effort 
and  conflicting  assessments  caused  by  lack  of  coordination.  The  TPIPT  process  seems  to  offer  the  best 
method  for  facilitating  coordination  and  eliminating  duplication  of  effort. 

(2)  Because  the  TPIPT  process  is  still  in  the  formation  stages  and  TPIPTs  are  in  the 
formation  stages,  there  currently  are  no  lessons  learned  available . 

e.  BEST  PRACTICES: 

(1)  WL/XP  is  currently  in  the  process  of  putting  guidance  together  on  how  to  perform 
technology  assessment.  This  process  may  be  useful  when  completed. 

(2)  HQ  AFMC/XRX  is  working  in  coordination  with  Air  Combat  Command,  HQ  ACC,  to 
develop  command  guidance  on  the  TPIPT  process.  Contact  HQ  AFMC/XRX.  DSN  787-7119  for 
additional  information. 
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f.  rWAPS: 

(1)  Failure  to  use  the  TPIPT  process  which  involves  aH  the  proper  stakeholders  in  a 
coordinated  eftort  will  likely  result  in  duplication  of  effort  and  conflictmg  assessments  the  same 
technology  development  programs 

(2)  Technology  development  is  like  life,  it  goes  on.  You  can  corttinue  to  search  tor  and 
evaluate  technology  developments  forever.  Therefore,  the  scope  of  Technology  Area  Assessment 
activities  should  be  clearly  defined  and  reasonable  time  constraints  should  be  placed  on  technology 
assessment  efforts. 
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1.  ELEMENT:  D7,  TBS  0.1 .7.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Assess  Non-materiel  Altematives  Support  (As  Required) 

3.  ELEMENT  OWNER<S):  Product  Centers 

4.  ELEMENT  STAKEHOLOER(S):  Operating  Commands.  Headquarters  USAF/XO,  Air  Force  Studies 
and  Analysis  Agency  (AFSAA) 

5.  REQUIREMENT: 

a.  DoD  Directive  5000.1,  Defense  AcQuisition.  23  Feb  91,  Part  1,  directs  examinirrg  non-materiel 
solutions  as  part  of  evolutionary  requirements  definition. 

b.  DoD  Directive  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures.  23  Feb  91 , 
Part  3,  directs  examining  non-materiel  solutions  as  part  of  the  determination  of  mission  needs. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Evaluate  the  potential  of  non-materiel  solutions  to  resolve  the  deficiencies  found 
during  the  campaign  level  deficiency  analysis. 

b.  Objective:  Determine  whether  the  need  can  be  satisfied  without  the  necessity  of  developing  a 
materiel  solution. 

7.  DESCRIPTION:  Non-materiel  solutions  are  those  f'^ngs  that  do  not  require  the  acquisition  of  new 
hardware,  such  as  changes  in  doctrine,  operational  corioepts,  support  concepts,  strategy,  tactics,  training 
or  organization.  A  variety  of  procedures  may  be  necessary  to  examine  the  impact  of  these  changes, 
from  detailed  mission  level  effectiveness  analyses  to  campaign  level  studies  (especially  for  changes  in 
doctrine).  The  responsibility  for  defining  and  accomplishing  these  analyses  is  with  the  operating 
command  that  is  in  the  best  position  to  define  the  parameters  and  variations  to  be  considered.  The 
impact  of  these  changes  can  often  be  assessed  using  Product  Center/XR's  analysis  capability.  The 
Product  Center  XR  will  draw  upon  its  organic  capability  and  numerous  other  sources  in  assisting  the 
operating  command  assess  non-materiel  alternatives.  These  sources  include  support  contractor 
analysis,  laboratory  analysis,  other  System  Program  Offices.  Technology  Planning  Integrated  Product 
Teams  and  other  government  agencies  such  as  Advanced  Research  Projects  Agency,  United  States 
Army  Training  and  Doctrine  Command,  United  States  Navy  organizations,  operating  command  study 
groups  (e.g.,  Air  Combat  Command's  Joint  Studies  Group), ,  and  the  AFSAA.  To  effectively  complete 
this  element,  the  responsible  agency  must  have  the  output  of  the  predecessor  block,  D4.  Also  this 
element  is  iterative  in  nature  in  that  it  constantly  feeds  its  results  to  C7,  while  the  user  feeds  D7  initial 
and  additional  information  so  the  user  may  accomplish  C7. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  This  activity  can  begin  when  the  operating  command  has  determined  that  a 
deficiency  exists  and  requests  a  Product  Center's  assistance  in  assessing  non-materiel  alternatives  for 
meeting  the  deficiency.  (Product  Centers  can  support  the  opiating  command  in  determining  the 
deficiency.  This  establishes  the  baseline  against  which  non-materiel  and  materiel  solutions  can  be 
assessed.) 

b.  Exit:  The  activity  is  complete  when  the  operating  command  has  determined  that  all  non¬ 
materiel  approaches  have  been  adequately  examined. 
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9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs; 

(1)  Defined  scenarios,  missions,  and  tasks,  C6. 

(2)  The  necessary  guidance  from  the  operating  command  on  the  exact  service  expected 
from  the  center,  C7 

(3)  The  data  previously  generated  by  the  center  as  they  assisted  the  operating 
command  with  deficiency  analysis,  D4 

b.  Outputs: 

(1)  Determination  of  whether  a  non-matenel  solution  to  the  deficiency  exists.  If  anon- 
materiel  solution  does  not  exist,  the  results  are  fed  to  Cl 2. 

(2)  The  results  of  this  element  are  fed  to  C7.  The  operating  command  then  either 
provides  further  input  to  the  center  on  the  assistarice  they  need  or  closes  activity  on  this  element. 

10.  KEY  REFERENCES; 

a.  AF  Instruction  1 0-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,  1 6  February  1 993,  par  1 . 1 .6. 1 ,  provides  information  on  the  types  of  non-materiel  solutions 
that  the  should  be  addressed. 

b.  AF  Policy  Directive  10-6,  Air  Force  Mission  Needs  and  Operational  Requirements  Process, 

1  Aug  92,  par  1 .3,  directs  examining  non-mate.'iel  solutions  before  proceeding  to  material  solutions  and 
directs  that  a  mission  need  statement  will  only  be  developed  after  non-materiel  options  are  found 
unsatisfactory. 

11.  IMPLEMENTATION  TOOLS: 

a.  Campaign  level  force  optimization  model 

b.  An  optimization  process  for  force  allocation  can  be  used  in  the  campaign  analysis  to 
determine  the  best  strategy  and  operational  concept. 

c.  Hierarchy  of  analysis  tools  from  campaign  level  to  mission/effectiveness  level  and  possibly 
performance  level  r^els 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Varies  from  a  few  days  to  months  depending  on  magnitude  of  assistance 
requested. 

b.  CONSTRAINTS;  Driven  by  need  dates  for  mission  needs  analysis  (MNA)  in  support  of  MS  0 
decisions  -  part  of  supporting  analysis  required  for  the  MNA. 

c.  RESOUF  CES:  From  one  to  several  personnel  including  analysts,  logisticians,  and 
engineers.  Various  campaign  and  mission/effectiveness  models  for  analysis. 

d.  LESSONS  LEARNED:  Requires  a  hierarchy  of  analysis  tools  from  campaign  level  to 
effectiveness/performance  level. 
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e.  BEST  PRACTICES:  Maintaining  close  liaison  with  the  operator  will  help  define  areas  where 
the  capabilities  of  Product  Center  can  best  be  used  to  support  non-materiel  solution  analyses. 

f.  TRAPS: 

(1) .  Not  doing  complete  analysis  -  not  getting  operating  command  signed  up  initially 
with  ground  rules/assumptions  for  the  analysis. 

(2) .  Using  undefined  scenario/mission  rrxxfels  or  models  that  are  not  validated. 
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1.  ELEMENT:  D9.  TBS  0.1.9.1  (IFC  93-3) 

2.  ELEMENT  TITLE:  Develop  Preliminary  System  Concept  Options 

3.  ELEMENT  OWNERS: 

a.  Operating  Command 

b.  Product  Center  XR(s) 

4.  ELEMENT  STAKEHOLDERS: 

a.  Implementing  and  Supporting  Commands 

b.  Air  Force  Studies  and  Analysis  Agency  (AFSAA) 

c.  Headc^arters  United  States  Air  Force  (USAF) 

d.  Air  Force  Materiel  Command  (AFMC)  Technical  Planning  Integrated  Product  Teams  (TPIPTs) 

e.  Supporting  Centers  &  Agencies 

f.  Laboratories 

g.  Industry 

5.  REQUIREMENT: 

a.  OODI  5000.2,  Defense  Acquisition  Management  Policies  &  Procedures.  Jan  91 : 

(1)  Part  2,  Section  B,  General  Policies  &  Procedures, 

(2)  Part  3,  Section  2,  Determination  of  Mission  Need. 

(3)  Part  4,  Requirements  Evolution  and  Affordability,  and 

(4)  Part  7,  Logistics  &  Other  Infrastoicture  for  total  system  concerns; 

b.  DODI  ^00.2-M,  Defense  Acquisition  Management  Documentation  &  Reports,  Feb  91,  Part  2, 
Mission  Need  Statement; 

c.  AF1 10-601 ,  Mission  Needs  &  Operational  Requirements  Guidance  &  Procedures.  Feb  93, 
Instnjction  for  developing  &  processing  AF  mission  needs  and  operational  requirements; 

d  Military  Standard  (MIL-STD)  -  499B,  Systems  Engineering,  Draft  May  92,  Section  3.8, 

Systems  Engineering  Process. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Provide  the  Operating  Command  with  preliminary  insight  to  potential  concept 
alternatives  that  address  their  evolving  draf'  mission  need. 

b.  Objectives: 

1 )  Quantitatively  define  the  desired  operational  and  functional  needs  at  the  task  level 

(task-to-need); 

2)  Identify  preliminary  concept  alternatives  to  be  applied  against  the  evolving  draft 

mission  need; 

3)  Provide  system-level  concept  trades  and  sensitivities  data  that  relate  to  draft 
operational  requirements. 

7.  DESCRIPTION: 

The  initial  deficiency  analysis  (reference  C3,  Mission  Needs  Analysis)  is  performed  at  the 
regional  scenario  level  and  addresses  the  overall  capability  of  an  integrated  force  to  acconplish  the 
regional  objectives.  Once  a  deficiency  is  identified  at  this  level  and  it  is  determined  that  non-materiel 
solutions  are  not  feasible,  an  assessment  of  the  operational  capability  needs  for  each  mission  scenario  of 
the  regional  analysis  must  be  conducted.  To  accomplish  this,  the  scenarios  must  be  decomposed  into 
segments  which  are  then  individually  evaluated  to  determine  the  capabilities  needed  to  improve  the 
ability  to  accomplish  the  mission.  An  important  element  of  this  activity  is  the  establishment  of  a  Threat 
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Steering  Group  (TSG)  to  ger^erate  an  approved  threat  data  base.  The  TSG  is  typically  made  up  of 
members  from  the  intelligence  community  (e.g.  Foreign  Aerospace  Science  and  Technology  Center  - 
FASTC.  AF  Intelligence  and  Support  Agency  -  AFISA,  Operating  Command  intelligertce  division  -  /IN. 
etc)  and  technical  analysts.  The  threat  data  base  serves  as  a  reference  for  assessing  and  comparing  the 
various  system  concept  alternatives  and  often  assists  in  establishing  the  capability  levels  for  the  potential 
alternatives. 

A  first  step  is  to  conduct  a  sensitivity  analysis.  From  a  baseline  force  allocation,  selective 
changes  in  the  analysis  will  reveal  how  the  force  allocations  and  scenario  outcorrte  are  affected.  For 
example,  if  the  ability  of  an  interdiction  asset  to  destroy  command  and  control  facflities  is  parametrically 
varied,  the  impact  of  these  changes  on  the  overall  outcome  can  be  measured.  By  systematically 
addressing  each  operational  capability,  it  is  possible  to  determine  which  improvements  are  most 
beneficial  to  resolving  the  deficiencies  which  are  measured  in  terms  of  the  overall  outcome.  The 
boundaries  on  possible  improvements,  in  terms  of  technical  feasibility  and  affordability,  need  to  be 
assessed  to  define  the  tasks  that  should  be  examined  in  more  detail  in  Phase  0.  Con^rrently,  some 
insight  is  gained  into  the  relative  merits  of  various  combinations  of  ope.ational  capability  improvements 
that  will  achieve  the  same  overall  level  of  deficiency  resolution. 

The  preliminary  system  concepts  rruist  reflect  functional  capabilities  that  allow  the  achievement 
of  the  desired  operational  capabilities  in  order  to  identify,  integrate  and  assess  various  potential 
technologies.  For  example,  if  the  operational  capability  desired  is  to  achieve  a  specified  level  of  kill 
effectiveness  against  a  column  of  tanks,  various  combinations  of  functional  capabilities  (e.g.  sensor 
performance,  weapons  load,  speed,  turn  rate,  etc.)  can  be  defined.  The  definition  of  pertinent 
parameters  for  each  operational  capability  and  the  range  of  values  for  each  parameter  will  allow  the 
development  of  a  set  of  configurations  for  each  conceptual  approach  which  satisfies  the  desired 
functional  capabilities. 

The  conceptual  synthesis  activity  produces  system-level  concepts  to  implement  evolving 
functional  architectures  and  provides  information  for  evaluating  the  capability  of  the  concept  to  satisfy 
operational  requirements.  Synthesis  is  defined  as  the  performance,  configuration,  and  arrangement  of  a 
given  system  and  its  elements,  including  test,  operation,  and  support  areas  of  concern.  This  may  be  a 
set  of  schematic  block  diagrams,  physical  and  mathematical  models,  computer  simulations,  layouts, 
drawings,  and  similar  engineering  graphics.  These  portrayals  should  illustrate  intra-  and  inter-  system 
interfaces  and  permit  traceability  between  the  elements  at  various  levels  of  system  detail.  Conceptual 
designs  are  used  as  a  framework  from  which  to  develop  cost,  schedule,  performance  and  risks,  including 
technology  availability  and  maturation  (077). 

To  assess  the  potential  for  improvements,  technology  projections  are  used  to  define  advances 
that  could  be  available  in  the  time  frame  of  the  deficiency  or  need.  These  technologies  are  represented 
in  the  preliminary  concepts  to  determine  their  impact  in  the  total  system  context.  The  integration  effects 
of  the  technologies  will  be  dependent  upon  the  concepts  considered,  so  the  broadest  possible  set  of 
concepts  should  be  considered.  Other  sources  of  potential  system  approaches  include  existing 
(operational  or  development)  assets  of  U.S.  commercial  (D13),  allied  or  other  foreign  countries  (D14). 
Efforts  should  be  taken  to  identify  any  candidates  from  these  sources  and  include  them  in  the  list  of 
preliminary  system  options.  This  approach  should  also  be  applied  when  considering  any  major 
subsystem,  for  both  operational  (in  the  field)  and  development  (in  a  laboratory  or  dem/val  area) 
perspectives  (D29,  D30). 


Another  principle  activity  is  the  development  of  rough-orders-of-magnitude  (ROMs)  estimates  of 
the  operational  effectiveness  (capability,  risk  and  life  cycle  cost)  of  the  various  concepts.  The  concepts 
are  exercised  in  the  mission  scenario(s)  to  determine  the  capability  for  "successfully"  completing  the 
simulated  operational  tasks.  This  part  of  the  effort  is  a  skeleton  of  the  real  assessment  to  come  later 
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(during  Phase  0)  in  the  COE  A  (Cost  &  Operational  Effectiveness  Analysis).  An  important  aspect  of  this 
development  is  the  identification  of  the  measures  of  success,  since  this  wHI  be  the  criteria  for  evaluating 
the  relative  merits  of  the  preliminary  system  concepts.  For  example,  in  a  case  where  the  deficierKy 
refers  to  combat  needs,  the  analyses  could  erxximpass  survivability  in  one-on-one  (i.e.  system  versus 
system)  situations,  mission  scenario  levels  (analytical  aggregation  of  the  one-on-one  cases)  and  regional 
outcomes  (analysis  combined  at  the  next  summary  level).  Each  level  of  the  effectiveness  analysis  will 
identify  and  address  a  set  of  critical  parameters  that  determine  the  relative  merits  of  the  corwepts. 

These  parameter  sets  can  be  viewed  from  a  top-down  development  perspective  (i.e.  successive  levels  of 
detail),  with  attention  being  given  to  maintaining  connectivity  throughout  the  levels  (D1 7,  C1 1 ). 


8.  ENTRANCE/EXIT  CRITERIA: 

a.  EiiudiK;e:  The  activity  is  initiated  when  requested  by  the  Operating  Command  to  support 
their  drafting  of  a  MNS  by  assessing  the  deficiency  area  through  desired  operational  capabilities  and 
potential  materiel  approaches.  This  is  a  precursor  to  the  Operating  Command's  sending  the  draft  out  for 
comments  and  coordination. 

b.  Exit:  The  activity  is  an  iterative  process  and  continues  until  the  Operating  Command  has 
finalized  their  MNS,  a  draft  of  Phase  0  plans  has  been  developed,  and  the  documentation  has  been 
completed. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  C3,  Mission  Need  Analysis  (MNA):  {includes  C6/D4  &  C7/D7] 

(a)  Identification  of  major  program  planning  objectives  of  the  Defense 

Planning  Guidance  (DPG)  to  which  the  need  responds. 

(b)  Description  of  the  mission  need,  deficiency  or  opportunity. 

(c)  Descriptions  of  the  scenario(s),  baseline  assets  &  threat  information. 

(d)  Description  of  why  non-material  alternatives  were  judged  inadequate. 

(e)  Description  of  constraints,  groundrules  and  assumptions. 

(f)  Description  of  Concept  of  Operations  (CONOPS). 

(2)  Cl  1,  Preliminary  Impacts  Program  Plan  (IPP). 

(3)  Cl 2,  Preliminary  MNS  package. 

(4)  D29,  Consider  industry  participation. 

(5)  D30,  Evaluate  laboratory  advanced  technology  development,  demonstration,  and 

transition. 

(6)  D1 3,  Determine  applicability  of  non-developmental  items  (NDI). 

(7)  D14,  Determine  suitability  of  cooperative  development  (COD). 

(8)  D77,  Preliminary  cost  estimates. 


b.  Outputs: 

(1)  Cl  2,  Preliminary  mission  need  statement. 

(a)  Identifies  potential  materiel  alternatives  and  areas  of  study. 

(b)  Describes  &  updates  constraints,  groundmles  &  assumptions. 

(2)  Cl  1 ,  Preliminary  Impacts  Program  Plan. 

(3)  D13,  Determine  applicability  of  NDIs;  potential  area  of  application. 

(4)  D14,  Determine  suitability  of  COD;  potential  area  of  application. 

(5)  D1 5,  Build  and  maintain  program  database:  results  from  setup  and  execution  of 

concept  analyses. 

(6)  D29,  Consider  industry  participation. 

(7)  D30,  Evaluate  laboratory  advanced  technology  development,  demonstration,  and 
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transition. 

(8)  D77,  Preliminary  cost  estimates. 

(9)  D17,  Update  Mission  Area  Development  Plan  (MAOP). 

10.  KEY  REFERENCES: 

Section  5.  Requiremenl(s)  plus; 

a.  AF  Sup  1/  DODI  5000.2,  Acquisition  Managemert  Policies  &  Procedures. Sep  92,  Part  2. 
Section  B.  Policies  for  interface  management. 

b.  MIL-HNBK-499-3,  System  Engineering  /  Configuratbn  Management  (SE/CM)  -  Life  Cycle 
Application,  Draft  Aug  92, 

c.  MIL-STD-1388-1 A,  Logistic  Support  Analysis  (LSA),  Apr  83,  provides  general  requirements 
and  task  descriptions  for  performance  of  LSA. 

11.  IMPLEMENTATION  TOOLS: 

The  previous  references  and  the  following  notations  provide  sources  for  additional  information 
that  pertains  to  the  setup  and  execution  of  the  preliminary  assessments  for  this  Pre-Milestone  0  activity. 

a.  Design  synthesis  and  analysis  models. 

b.  Mission  analysis  and  effectiveness  models. 

c.  Requirements  allocation  sheet  (RAS). 

d.  A  baseline  concept  description  (BCD)  sheet  is  used  to  collect  the  performance  requirements 
and  constraints,  as  delineate  by  functional  analysis,  that  apply  to  an  individual  system  concept. 

e.  A  schematic  block  diagram  is  used  to  develop  and  portray  the  conceptual  schematic 
arrangement  of  system  elements  to  meet  system  and  or  subsystem  requirements. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  successful  execution  of  this  element  takes  approximately  6  •  9  months  for 
a  full  system-level  deficiency. 

b.  CONSTRAINTS:  Funding  availability  will  impact  the  scope  of  resources  that  can  be  applied 
to  the  activity.  Special  security  facilities  and  computatioriai  resources  are  typically  required  to 
incorporate  special  technologies  or  Special  Access  Program  (SAP)  information  into  the  concepts. 
Operating  Command  priority  may  affect  the  timing  and  availability  of  analysis  resources  to  address 
specific  deficiencies. 

c.  RESOURCES:  This  activity  typically  takes  a  team  of  10-20  analysts  and  planning  personnel, 
the  size  depending  on  the  number,  type  and  complexity  of  the  corx;epts  to  assessed.  Representation 
from  functional  disciplines  should  be  based  on  a  balanced  system  perspective. 

d.  LESSONS  LEARNED: 

From  ALLCARS  data  base  -- 

(1)  871 ,  Timely  Submission  of  Trade  Studies  by  Contractors. 

(2)  1848,  Integrated  System  Design  and  Analysis. 

e.  BEST  PRACTICES: 

(1)  Involve  full  team  of  stakeholders,  especially  the  Operating  Command. 

(2)  Develop  a  realistic  schedule. 

(3)  Maintain  task  order  agreements  with  industry  (siudy  organizations  and  maior 
airframers)  for  efficient  implementation. 
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f.  TRAPS: 


(1 )  Exceeding  conceptual  d^ils:  this  is  often  a  significani  pitfall  encountered  by  the 
protect  team.  They  must  maintain  an  awareness  that  the  primary  objective  of  the  pre-MS  0  activities  is 
to  develop  a  dear  description  of  the  MAJCOM’s  mission  need.  The  preliminary  investigation  of  potential 
materiel  approaches  is  to  assist  in  developing  a  better  understanding  of  the  scope  of  any  foHow-on 
activities. 


(2)  Concepts  driving  operational  requirement  levels.  Similar  to  (1 )  above,  the  weakness 
is  to  get  too  engrossed  in  investigating  the  potential  alternatives,  to  the  point  of  the  conc^s  irKficectly 
(or  directly,  in  some  cases)  impacting  any  mission  operational  levels  that  are  just  being  identified. 

(3)  Considering  only  evolutionary  approaches.  There  is  a  terxfency  to  start  with  a 
Tcnown  reference  point"  and  broadly  extrapolating  to  the  tftneframe  of  the  mission  need.  At  this  early 
stage  of  definitizing  a  mission  need  and  investigating  preliminary  corx:ept  approaches,  it  is  a  good 
opportunity  to  break  away  from  these  standards  and  expand  the  thinking  to  innovative  ideas  and 
approaches 
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1.  ELEMENT:  D13,  TBS  0.1.9.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Determine  Appiicabilily  of  Non-Oevetopmental  Items  (NDI) 

3.  ELEMENT  OWNER(S):  The  Office  of  the  Assistant  Secretary  of  Defense  for  Production  and 
Logistics  (OASD  (P&L)  SDM)  is  charged  with  overseeing  DoD  activity  as  it  relies  to  NDI  procurement. 

4.  ELEMENT  STAKEHOLDER(S):  Developing  Protect  office.  Operating  Command.  Air  Force 
Competition  Advocate.  OSD/DUSO(AR)  The  Deputy  Under  Sectetary  of  Defense  for  Acquisition 
Reform. 

5.  REQUIREMENT: 

a.  DODI  Directive  5000.1 .  Defense  Acquisition.  Part  i ,  page  4.  Para  1  .c.  23  Feb  91 .  states 
maximum  practicable  use  shall  be  made  of  commercial  arrd  c^her  non-developmental  items.  In 
describing  these  items,  maximum  practicable  use  shall  be  made  of  non-government  standards  arxl 
commercial  item  descriptions. 

b.  DODI  5000.2.  Defense  Acquisition  Management  Policies  and  Procedures,  Part  6,  Section  L; 
Part  6,  Section  H,  para  3.a.(3);  Part  3,  page  3-1 1 :  and  Part  10.  Section  C.  para  2d.  Non-Developmental 
items,  23  Feb  91 ,  states  policies  and  procedures  which  establish  the  basis  for  cost-effective  use  of 
commercial  products  and  other  non-developmentai  .terns  in  defense  systems  and  equipment. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  element  is  to  investigate  purchasing/using  existing  products 
or  systems  rather  than  pursuing  development  of  new  items. 

b.  Objective:  Identify  existing  or  emerging  products/technology  that  has  potential  to  save  life 
*  cycle  cost.  The  following  objectives  can  be  used  to  analyze  potential  products/technology; 

(1)  Reduced  devetopHnental  cost 

(2)  More  rapid  fielding 

(3)  Proven  capability/reliability 

(4)  Increased  competKion 

(5)  Established  logistics  support 

(6)  Tech  data  developed 

(7)  The  item  is  likely  state-of-the-art 

(8)  Competitive  Forces  have  shaped  its  functionality 

(9)  Existing  established  market 

(10)  Reduced  risk 


7.  DESCRIPTION: 

a.  This  is  a  preliminary  look  at  non-developmental  Hems.  Only  a  brief  outline  of  NDI  can  be 
accomplished  in  the  early  stages  of  the  project. 

b.  At  this  stage,  preliminary  concepts  are  being  defined  to  support  development  of  the  MNS 
(D9  arxf  Cl  2).  The  Air  Force  will  investigate  industry's  available  off  the  shelf  items  and  will  investigate 
them  for  satisfying  Air  Force  needs  (D29).  To  monHor  industry  and  participates  in  government  programs 
through  IR&D,  RFIs,  RFPs,  or  Other  Means  (D29).  In  this  area,  DoD's  influence  on  industry  is  primarily 
through  Small  Business  Innovation  Research  (SBIR)  and  Independent  Research  and  Development 
(IR&D)  activHies.  DoD  activHies  invHe  small  business  firms  wHh  strong  research  and  development 
c^pabilHies  in  scierKe  and  engineering  to  sutynH  proposals  under  the  SBIR  program.  The  objectives  of 
this  program  include  stimulating  technological  innovation  in  the  private  sector,  strengthening  the  role  of 
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small  business  in  meeting  DoO  research  and  development  needs,  fostering  and  encouraging 
participation  by  minority  and  disadvantaged  persons  in  technological  innovation,  and  increasfog  the 
commercial  appfication  of  DoO-supported  research  or  research  and  development  results.  Determining 
applicability  of  Non-Deveiopmental  Items  NDI  (D13)  is  accomplished  in  a  parallel  time  frame  with  D14. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  A  material  need  has  been  identified  and  preliminary  options  are  being 
formulated. 

b.  Exit;  To  exit,  identify  preliminary  performance  ranges,  thresholds,  and  trade-offs  associated 
with  what  is  known  about  NDI  at  this  point  of  the  project.  Also,  perform  a  preliminary  investigation  of 
alternative  logistics  support  strategy. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs; 

(1)  Requires  a  description  of  the  preliminary  mission  need  from  D9. 

(2)  Results  from  market  surveillance  of  laboratories  and  the  industrial  base  through 
trade  shows  and  trade  magazines  is  the  primary  method  tor  gaining  knowledge  of  existing  technology 
and  products  (D29).  A  cost  effective  analysis  should  be  performed  on  the  item  to  find  if  it  is  a  viable 
solution  to  the  item  needed. 

b.  Outputs;  Provide  the  Operating  Command  with  insight  to  potential  concept  alternatives  that 
address  his  draft  mission  need  (D9).  It  is  important  that  selected  NDI  alternatives  flow  back  into  this 
element  so  they  can  be  integrated  in  a  realistic  need. 

10.  KEY  REFERENCES: 

a.  Title  10  U.S.C.  2325,  Preference  for  Non-Developmental  Items,  18  Oct  87.  This  section  of 
Title  1 0  mostly  describes  Congressional  mandate  to  the  Air  Force  to  look  at  and  use  NDI  in  a  weapon 
system  whenever  possible. 

b.  Proposed  Strategic  Plan  to  Pursue  Acquisition  Reform,  8  Jun  93.  Contains  draft  information 
on  using  NDI  as  an  preferred  alternative  to  developing  new  systems  and  establishing  a  group  of 
advisors  OSO/DUSO(AR)  to  help  in  NDI  procurement. 

11.  IMPLEMENTATION  TOOLS: 

a.  Trade  magazines  and  trade  shows  for  market  surveillance. 

b.  Buying  ND/SD-2,  Oct  90.  Contact  Office  of  the  Assistant  Secretary  of  Defense  (Production 
and  Logistics),  Washington,  D.C.  20301-8000.  This  tool  mainly  describes  the  buying  process  for  NDI. 

c.  Market  Analysis  for  Non-Developmental  Items,  SD-5.  Contact  Office  of  the  Assistant 
Secretary  of  Defense  (Production  and  Logistics),  Washington,  D.C.  20301-8000.  Describes  NDI  as  an 
excellent  aHemative  to  business  as  usual. 

d.  Joint  Command  Commercial  Off-the-Shelf  (COTS)  Supportability  Working  Group  (CSWG) 
Rnal  Report,  June  91 .  Contact  ASC/SDC.  Describes  the  life  cycle  concerns  of  NDI.  This  is  an 
excellent  guide  and  is  highly  recommended  to  anyone  who  is  considering  the  use  of  NDI. 
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12.  PLANNmG  GUIDANCE: 

a.  DURATION:  You  should  start  with  the  Mission  Need  Statement  (MNS)  and  the  Government 
Systems  Requirement  Analysis  to  get  a  handle  on  the  architecture/configuration  akematives.  This  is  an 
ongoing  process  throughout  pre-Miiestone  0  to  Milestone  I  artd  wM  vary  in  duration  depending  on 
complexity  of  the  identified  mission  need. 

b.  CONSTRAINTS:  As  always,  timing  is  a  major  constraint,  because  if  NDI  is  selected  earfy  it 
may  become  obsolete  and  out  of  production  by  the  time  the  weapon  system  is  fielded.  You  have  limiled 
data  rigNs  with  NDI,  no  configuration  control,  and  no  existing  AF  support  stoicture. 

c.  RESOURCES:  All  functional  areas  need  to  be  involved  in  NDi.  Much  of  their  involvement 
will  be  in  the  requirements  area.  There  will  be  a  low  level  of  man-hours  with  NDI  at  this  stage  of  the 
project.  Most  of  the  man-hours  will  be  put  into  the  very  important  requirements  area  so  that  realistic 
requirements  levels  will  be  defined  and  a  better  selection  of  NDI  wiH  be  made. 

d.  LESSONS  LEARNED:  There  were  7  lessons  learned  in  the  Automated  Lessons  Learned 
Capture  and  Retrieval  System  (ALLCARS)  data  base.  The  numbers  are  1449,  20009, 20012,  20016, 
20045,  20047, 20084.  These  items  all  dealt  with  logistical  support  problems  arxf  problems  with  slightly 
modified  NDI  items.  Therefore,  pay  special  attention  to  these  areas  when  consid^ng  NDI. 

e.  BEST  PRACTICES:  If  NDI  is  not  considered  at  the  early  stages  of  the  acquisition  cycle  then 
you  probably  will  not  be  able  to  acquire  it  as  a  NDI  item  later. 

f.  TRAPS  Not  taking  the  follow-on  support  and  possible  added  life  cycle  costs  into  account 
when  using  NDI.  Too  much  modification  usually  negates  any  life  cycle  cost  savings. 
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1.  ELEMENT:  D14,  TBS  0.1.9  3  (IFC  93-3) 

2.  ELEMENT  TITLE:  Determine  Suitability  of  Cooperative  Development  (CD) 
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3.  ELEMENT  OWNER(S):  Deputy  Under  Secretary  of  Deferrse  (International  Programs)(DUSD(IP)). 
Assistant  Undersecretary  of  Defense  for  Programs  &  Acquisition  (USDA(P&A)).  SAF/AQXI,  AFMC/IA,  & 
WUXPI 

4.  ELEMENT  STAKEHOLOER(S):  Project  Office 

5.  REQUIREMENT: 

a.  DoDI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb  91,  Part  3,  pg.  3- 
9,  and  Part  5,  Section  F,  Para  3E.  This  identifies  the  requirement  to  consider  potential  cooperative 
research  and  development. 

b.  DoD  5000.2-M,  Defense  Acquisition  Management  Documentation  and  Reports,  Feb  91 ,  Part  4, 
page  4-4-1.  This  provides  format  for  CD. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  potential  for  International  Cooperative  Research  and  Development  of  military 
equipment  is  a  rer^ired  alternative  to  be  addressed  in  developing  a  Mission  Need  Statement  (MNS)  for 
an  identified  deficierKy  at  Milestone  0.  A  formal  Cooperative  Opportunities  Document  (COD),  with 
updates,  will  be  required  at  Milestone  I  and  beyond  (see  DoDI  5000.2  for  details). 

b.  Objective:  To  determine  if  CD  alternatives  are  applicable  for  the  identified  mission  need.  The 
first  brief  outline  of  applicable  CD  items  should  be  identified. 

7.  DESCRIPTION: 

a.  The  main  activity  is  to  determine  optional  concept  approaches  which  address  the  mission 
need  of  the  project  (D9).  NDI  (D13)  which  is  a  parallel  activity  is  accomplished  in  conjunction  with  CD 
(D14).  Output  is  the  formulation  and  evaluation  of  the  Systems  Concept  Option  (SCO)  (D9),  whicn 
provides  the  Operating  Command  with  insight  to  potential  concept  alternatives  (such  as  CD)  that  address 
his  draft  mission  need. 

b.  The  DoDI  5000.2  requirement  for  assessing  CD  mandates  the  consideration  of  buying  allied 
systems  or  cooperating  between  our  various  allies  on  development,  before  initiation  of  a  new  acquisition 
program.  A  CD  assessment  is  required  for  Acquisition  Category  (ACAT)  I  programs  and  cooperative 
opportunities  should  be  investigated  as  part  of  the  acquisition  strategy  for  ACAT  II,  III,  and  IV  programs. 
Specifically,  DoDI  5000.2  specifies  an  order  of  prefereixie  for  rrew  programs  as  follows; 

(1)  Use  or  rrxxlification  of  an  existing  U  S.  military  system. 

(2)  Use  or  rrxxfification  of  an  existing  commercially  developed  or  Allied  system  that 
fosters  a  non-deveiopmental  acquisition  strategy. 

(3)  A  cooperative  research  and  development  program  with  one  or  more  Allied  nations. 

(4)  A  new  joint  Senrice  development  program. 

(5)  A  new  Sen/'ice-unique  development  program. 

c.  Cooperative  Development  must  be  addressed  during  this  stage  of  the  program  for  potential 
questions  at  the  Milestone  0  reviews  and  documentation  in  the  COD  at  Milestone  I. 
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8.  ENTRANCE/EXiT  CRITERIA: 


a.  Entrance:  A  materiel  need  has  been  idemified  and  options  need  to  be  investigated. 

b.  Exit:  To  exit,  you  should  conclude  that  there  are/are  not  potential  COO  alternatives  to  the 
identified  mission  need. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  A  deficiency  or  technological  opportunity  has  been  validated.  Key  inputs  on  the  flow 
chart  are:  09.  Systems  Conc^  Option  (SCO)  Formulation  and  Evaluation,  and  029.  Industry  Monitor 
and  Participates  in  Government  Programs  Through  IR&O.  RFIs.  RFPs.  or  Other  Means.  In  this  area. 
OoO's  influence  on  industry  is  primarily  through  Small  Business  Innovative  Research  (SBIR)  and 
Independent  Research  and  O^elopment  (IR&O)  activities.  OoO  activities  invite  small  business  firms 
with  strong  research  and  development  capabilities  in  science  and  engineering  to  submit  proposals  under 
the  SBIR  program.  The  objectives  of  this  program  include  stimulating  technological  innovation  in  the 
private  sector,  strengthening  the  rote  of  small  business  in  meeting  OoO  research  and  development 
needs,  fostering  and  erxxiuraging  participation  by  minority  and  disadvantaged  persons  in  technological 
innovation,  and  increasing  the  commercial  application  of  DoO-supported  research  or  research  and 
development  resuKs.  Oetermine  Applicability  of  Non- Developmental  Items  (NDI)  (013)  is  accomplished 
in  a  parallel  time  frame  with  CD  (014). 

b.  Outputs:  A  preliminary  list  of  potential  CO  systems/subsystems.  This  will  provide  the 
Operating  Command  with  insight  to  potential  concept  altemative  approaches  that  address  his  draft 
mission  need. 

10.  KEY  REFERENCES: 

HQ  AFMC/XT  Letter.  9  Mar  92.  Development  Planning  Relationship  to  International 
Opportunities.  This  describes  how  CD  is  integrated  into  the  program  life  cycle. 

11.  IMPLEMENTATION  TOOLS:  None  identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  amount  of  time  needed  to  accomplish  this  activity  is  dependent  upon  the 
complexity  of  the  mission  deficiency.  Forty  man-hours  of  the  project  management  team  is  a  nominal 
estimate.  Actual  schedule  duration  for  this  activity  is  closer  to  two  months.  The  rTX}st  significant 
element  of  time  is  the  request  for  feedback  that  is  transmitted  to  the  international  offices  by  the  project 
cadre. 


b.  CONSTRAINTS: 

(1)  Resources  (time  &  personal)  for  in  investigating  various  alternatives. 

(2)  Access  to  a  central  location  to  obtain  needed  information  on  existing  and  planned 
military  and  allied  nation  projects. 

c.  RESOURCES:  Requires  an  identified  focal  point  within  the  project  cadre  and  a  contact  in  the 
local  international  affairs  office  (i.e.  WL/XPI). 

d.  LESSONS  LEARNED:  There  are  no  lessons  learned  in  the  Automated  Lessons  Learned 
Capture  and  Retrieval  System  (ALLCARS)  database  on  this  item. 


9.  BEST  PRACTICES: 


(1)  Start  as  early  as  possible  compiling  information  on  U.S.  and  allied  programs  which 
could  be  evaluated  for  joint  program  applicability.  Consideration  to  buy  or  cooperate  at  or  near  the 
Milestone  I  decision  is  too  late  to  effectively  pursue  overseas  opportunities.  Investigation  of  overseas 
opportunities  must  begin  during  development  planning  or  (for  technology  push)  be  an  outgrowth  of 
ongoing  S&T  cooperation. 

(2)  The  Defense  Acquisition  Board  (DAB)  will  be  much  inclined  to  hold  up  programs  that 
have  not  investigated  ways  to  reduce  costs  to  the  U.S.  taxpayer  through  cooperation.  (D^ld  Yockey, 
Principal  Deputy  Under  Secretary  of  Defense  for  Acquisition;  Appearance  before  the  Senate  Armed 
Services  Committee,  12  Jun  90).  This  analysis  should  be  done  to  assist  in  making  a  decision,  not  just  to 
fill  out  the  paper  work! 

f.  TRAPS:  Doni  forget  to  establish  early  a  comprehensive  protection  and  technology  control 
program  to  identify  and  protect  classified  and  other  sensitive  information. 
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1.  ELEMENT:  D15.  TBSO.1.9.4  (IFC  93-3) 

2.  ELEMENT  TITLE:  Establish  Database 
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3.  ELEMENT  OWNERS:  Operating  Commands;  Implementing  Commands:  Product  Centers; 

Industry. 

4.  ELEMENT  STAKEHOLDERS:  Operating  Commands;  Implementing  Commands;  Product  Centers; 
Laboratories;  Industry. 

5.  REQUIREMENT: 

a.  Department  Of  Defense  Directive  (DODD)  5000.1 ,  Defense  Acquisition,  23  Febmary  1991 ; 

This  directive  establishes  a  disciplined  management  approach  for  acquiring  systems  and  material  that 
satisfy  the  operational  user's  needs. 

b.  DODD  8320.1 ,  Data  Administration,  26  September  1991 :  (On  order) 

c.  Air  Force  Policy  Directive  (AFPD)  10-6,  Mission  Needs  and  Operational  Requirements,  19 
January  1993:  This  directive  requires  the  implementation  of  the  DOD  5000  series  documents. 

d.  AFPD  37-1,  Information  Management,  5  April  1993:  This  directive  establishes  information 
manage  policy,  from  its  creation  through  its  disposition.  It  ensures  availability  of  information,  in 
support  ot  the  Air  Force  mission,  while  providing  for  the  public's  right  to  access. 

e.  AFPD  63-1 ,  Acquisition  System:  (On  order) 

f.  Air  Force  Regulation  (AFR)  55-43,  Management  of  Operational,  Test  and  Evaluation,  29  June 
1990:  Data  Management  is  covered  under  paragraph  5-12.  The  test  director  should  ensure  the  plan 
for  data  collection  and  analysis  has  been  implemented  befwe  testing  begins. 

g.  Military  Standard  (MIL-STD)-499B,  Systems  Engineering,  Draft:  The  decision  database  may 
be  digital,  defined  by  the  Government,  or  left  open  for  contractor  definition.  MIL-STD-499  encourages 
minimizing  deliverable  data  to  ensure  availability  to  the  government,  traceability,  and  compliance  with 
Ck)mputer-Aided  Acquisition  and  Logistics  Support  (CALS). 

h.  MIL-STD-881B,  Work  Breakdown  Structure  (WBS):  This  standard  establishes  criteria 
governing  the  preparation  and  employment  of  WBS  during  the  acquisition  of  designated  defense 
materiel  items.  WBS  requirements  established  by  this  standard  a^y  to  all  defense  materiel  items  or 
major  modifications. 

i.  MIL-STD-1388-1  A,  Logistics  Support  Analysis  (LSA),  1 1  April  1983:  The  goal  of  this  standard  is 
to  provide  a  single,  uniform  approach  by  the  military  services  for  conducting  activities  necessary  to 
m^e  supportability  requirements  an  integral  part  of  system  requirements  and  design.  LSA 
documentation  consists  of  alt  data  resulting  from  analysis  tasks  conducted  under  this  standard.  It  is 
the  primary  source  of  validated  supportability  data  pertaining  to  an  acquisition  program.  The  Chief  of 
Logistics  shall  ensure  LSA  documentation  is  developed  arxf  maintained  commensurate  with  design, 
support,  and  operational  concept  development.  Information  will  be  updated  in  a  timely  manner  using 
test  results,  configuration  changes,  operational  concept  changes,  and  support  concept  changes,  during 
the  acquisition  process. 

j.  MIL-STD-1388-2B,  DOD  Requirements  for  a  Logistics  Support  Analysis  Record  (LSAR),  28 
March  1991 :  This  standard  improves  the  cost  effectiveness  of  generation,  maintenance,  and 
acquisition.  It  uses  the  technical  data  provided  in  support  of  the  LSA  program.  Direction  is  provided 
for  standardization  of  I  .SAR,  consolidation  of  logistics  oriented  technical  information,  and  maximum 
use  of  industry  developed  integrated  data  systems. 
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k.  MIL-STD-1840A,  Automated  Interchange  of  Technical  Information,  22  December  1987  The 
purpose  of  this  document  is  to  standardize  the  digital  interface  between  organizations  or  systems.  It 
provides  guidance  in  the  exchange  of  digital  forms  used  for  technical  information  requirements  of 
logistic  support  weapon  systems,  throughout  their  life  cycle.  This  application  addresses  technical 
information  such  as  training,  maintenance  manuals,  and  their  associated  illustrations.  It  defines 
product  data  for  engineering  drawings  and  specifications  that  are  part  of  the  traditional  technical  data 
packages  used  for  Hern  acquisition.  This  evolving  data  concept  provides  for  transfer  and  archival 
storage  of  information. 

6.  PURPOSeOBJECTIVES: 

a.  PURPOSE:  The  purpose  of  the  Program  Database  is  to  provide  a  central  location  for  the 
collection  and  storage  of  accesses  to  all  data  associated  with  the  program.  This  data  will  support 
applicable  requirements  established  in  section  5  and  meet  the  information  needs  of  the  milestone 
d^ision  authority,  supporting  staff,  and  review  forums.  It  provides  an  audit  trail  of  the  rationale  for 
system  requirement's  evolution  that  starts  with  the  customer's  initial  request.  The  database  will 
eventually  contain  descriptions  of  the  system  products,  processes,  results  of  analyses,  ground  mles 
and  assumptions,  briefings  to  Senior  Leadership,  and  ail  applicable  program  information.  It  will 
support  access  by  tools  developed  for  program  documentation  management. 

b.  OBJECTIVES:  The  objective  of  the  Program  Database  will  be  to  iderrtify,  collect,  and  or 
generate  data  to  support  the  decision  process.  The  goal  would  be  to  establish  a  paperless  system  that 
will  be  accessible  by  all  essential  and  authorized  personnel,  including  contractors.  This  database 
would  be  the  primary  source  of  data  used  by  the  functional  staff  and  the  program  manager.  It  will 
provide  the  milestone  authority  with  current  and  historical  program  information  in  support  of  a  decision 
and  risk  or  impact  assessment.  It  will  provide  an  evolutionary  picture  of  the  weapon  system  acquisition 
that  is  upgraded  to  support  the  weapon  system  procurement  throughout  all  its  phases. 

7.  DESCRIPTION: 

a.  This  database  is  a  repository  of  information  used  and  generated  for  integrated  requirements 
capture,  correlation,  ranking,  decomposition,  and  rationalization;  inter-operability  constraints;  lessons 
teamed;  configuration  alternatives,  verifications,  decision  criteria,  trade  study  assessments,  and  any 
other  required  information.  It  may  incfode  physical  and  mathematical  models,  computer  simulations, 
layouts,  configuration  documentation,  and  technical  data,  as  appropriate.  A  good  structural  design 
effort,  up  front,  will  make  the  database  useful  for  the  milestone  decision  process.  The  database 
should  be  more  than  a  single  reposKory  of  information.  Newer  generations  of  software  can  tie  multiple 
sources  of  information  together  to  make  them  appear  as  a  single  source.  Databases  areni  just 
relational  anymore.  Software  applications  allow  you  to  access  virtually  any  combination  of  data, 
pictures,  drawings,  processes,  outputs,  etc. 

b.  The  goat  of  this  database  would  be  to  provide  the  user  access  to  all  the  pieces  of  a  project  or 
program  (e.g.,  financial  spreadsheets,  ^ineering  drawings,  videos,  briefirtgs,  and  test  data).  The 
performing  activity  will  select  the  specific  data  entry  media,  storage,  and  maintenance  procedures. 

User  identification,  data  requirements,  understanding  the  problem,  cost,  speed,  and  ease  of  use,  are 
probably  the  biggest  players  in  database  decisions. 

c.  An  operational  database  will  need  to  consider  the  requirements  of  MIL-STD-1388,  MIL-STD- 
499B,  MIL-STD-881B,  MIL-STD-1840A,  ANSI  ASC  X12,  Electronic  Data  Interchange,  CALS, 
Contractor  Integrated  Technical  Information  Service  (CITIS),  and  Integrated  Weapon  System 
Management  (IWSM).  The  management  information  system  should  provide  automated  tools  for 
engineers;  share  program  data  with  analyst,  contractors,  and  the  customer;  and  review  of  program 
data  cost  and  schedules.  There  should  be  a  paperless  delivery  of  required  data.  It  should  establish  a 
modular  system  that  has  a  data-dependent  and  data-driven  information  architecture.  The  B-2  system 
has  13  sites  corii,;sting  of  the  prime  contractor,  customer,  subcontractors  and  associate  contractors.  It 
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has  more  than  3000  users.  18  subsystems.  1270  screens,  1 .8  million  lines  of  code,  4  Gbytes  of  data, 
and  1 .3  miHion  transactions  per  month.  The  databases  consist  of  individual  automated  data  files, 
integrated,  using  operating  software,  with  output  applications  for  aU  project  team  elements. 

d.  Additional  files  should  be  developed  to  consolidate  data  tor  the  Pre-Conceptual  Phase,  and 
Concept  Exploration  and  Development.  These  files  should  be  integrated  with  a  selected  hierarchy  of 
analytical  models  that  will  accornplish  the  analysis  tor  campaign  missions,  air-to-air  combat,  one-on- 
one,  Time  Phase  Forces  &  Deployment  Data  (TPFDD),  Conventional  Mating  &  Ranging  Program 
(CMARPS),  Logistics  Composite  Model  (LCOM),  Computer  Aided  Logistics  Management  (CALM),  and 
additional  engineering  models.  The  results  of  the  analysis  should  include  supporting  rationale  for  each 
one  of  the  options  under  evaluation. 

e.  The  D1 5  database  focuses  on  documentation  from  the  Mission  Area  Assessment  (MAA)  and 
Mission  Needs  Analysis  (MNA).  It  will  receive  data  from  D9,  the  Preliminary  System  Concept  Option 
(PSCO)  study  effort  and  provide  support  data  for  the  Phase  O  Plans.  This  data  wilt  provide  the 
foundation  for  supporting  the  Mission  Need  Statement  (MNS). 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  ENTRANCE:  The  database  should  start  with  a  customer  rer^est  for  assistance  in  identifying  a 
potential  need  through  data  collection  in  support  of  the  MNA.  Place  emphasis  on  feasibility  and 
affordability  of  alternative  non-materiel  approaches  which  might  satisfy  the  deficiencies.  The  result  of 
the  PSCO  should  support  the  customer's  formulation  of  a  position  regarding  anticipated  deficiencies. 

b.  EXIT  CRITERIA:  The  D1 5  database  provides  current  information  for  the  Joint  Requirements 
Oversight  Council  (JROC),  Defense  Acquisition  Board  (DAB),  Industry,  and  the  Laboratories.  A  data 
package  will  be  prortoced  in  support  of  the  Preliminary  MNS,  the  Phase  0  Plan,  and  will  be  frequently 
updated,  throughout  the  acquisition  process. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  INPUTS: 

(1)  D9.  PSCO 

(a)  Accomplish  the  MNA  at  the  regional  scenario  level,  address  the  overall  capability  of  an 
integrated  force  to  accomplish  regional  objectives,  and  consider  non-material  solution  alternatives. 
Negative  results  will  require  an  assessment  of  the  operational  capability  for  each  mission  scenario 
used  in  the  regional  analysis.  Separate  the  scenarios  into  segments  and  individually  evaluate  the 
capabilities  needed  to  improve  the  ability  to  accomplish  the  missions. 

(b)  The  synthesis  activity  produces  system-level  concepts  to  implement  evolving 
functional  architecture's  and  provide  information  for  evaluating  the  capability  of  the  concepts  to  satisfy 
operational  requirements.  Conceptual  design  analysis  provides  the  data  for  developing  cost,  schedule. 
performance,  and  risks  assessments,  including  technology  availability  and  maturation. 

(c)  Results  from  effectiveness  trades  and  sensitivities  will  provide  the  Operating 
Command  some  insight  to  potential  concept  alternatives  that  may  resolve  the  identified  shortfall. 

b.  OUTPUTS: 

(1)  D1 7,  Update  Mission  Area  Development  Plans 

(a)  The  Mission  Area  Development  Plans  (MADPs)  are  documents  generated  by  the 
Technical  Planning  Integrated  Product  Teams  (TPIPTs)  at  ASC.  The  MADPs  are  standard  references 
tor  each  of  the  operating  MAJCOMs  and  contain  current  information  on  missions,  force  composition 
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and  stnicture,  threats  and  scenarkXs)  status,  mission  needs,  technology  base,  and  assessments  of 
activities  and  plans.  Annual  updates  are  planned  for  each  of  the  documents,  in  order  to  provide  the 
latest  status  in  the  areas  previously  mentioned.  The  ASC  TPIPTs  are  a  network  of  key  representmives 
from  operating  MAJCOMs.  (ACC/OR,  AFSOC/XP,  AMC/XR,  etc),  development  planners  (XR,  YX,  etc), 
system  program  offices  (SD,  YJ,  YA.  etc),  Wright  Laboratory  (XP,  MT,  etc),  intelligence  (FASTC)  and 
product  groups  (SM,  etc). 

(b)  One  of  the  functions  of  the  TPIPTs  is  to  recommend  and  or  monitor  assessments  of 
mission  deficiencies  (C12)  that  are  identified  through  the  MAJCOM's  MNA  (C3).  Periodic  information 
from  deficiency  assessments  provides  the  type  of  information  that  is  evaluated  and  incorporated  into 
the  MADPs  (09  &  01 5).  This  information  covers  areas  such  as  concept  alternatives,  enabling 
techrx>logies,  threat  descriptions,  etc.  The  MAOP  also  becomes  a  useful  reference  to  sources  for 
documentation  of  methodr^ies  used  to  generate  mission  needs,  identified  mission  needs,  and 
groundrules  used  in  setup  and  execution  of  the  various  assessments. 

(2)  020a,  Oevelop  Oraft  Phase  0  Plans 

(a)  Support  the  Operating  Command  in  identifying  and  documenting  constraints  and 
assumptions,  alternative  strategies,  required  tasks,  resources,  exit  criteria,  and  recommendations  for 
the  Ac^isition  Oecision  Memorandum  (AOM)  and  Program  Management  Oirective  (PMO). 

(3)  020b,  Oevelop  Oraft  Technical  Plans 

(a)  Incorporate  the  Systems  Engineering/Configuration  Management  (SE/CM)  philosophy 
into  the  process  and  complete  support  task  for  Phase  O  Plans.  These  activities  will  identify  tasks  and 
interfaces  by  functional  discipline,  initiate  technical  plan  development,  and  establish  specific  working 
groups.  The  scope  of  this  activity  will  establish  a  reasonably  accurate  technical  framework  for  the 
tasks  and  activities  that  are  starting. 

10.  KEY  REFERENCES: 

a.  0000  5000.1 ,  Oefense  Acquisition,  23  February  1991 :  This  directive  establishes  a  disciplined 
management  approach  for  acquiring  systems  and  material  that  satisfy  the  operational  user's  needs. 

b.  DOOO  8320.1 ,  Oata  Administration,  26  September  1991 :  (On  order) 

c.  000  Instruction  (0001)  5000.2,  Oefense  Acquisition  Management  Policies  and  Procedures,  23 
February  1991:  This  instruction  provides  an  integrated  framework  for  translating  broadly  stated 
mission  needs  into  stable,  affordable,  acquisition  programs  that  meet  the  operational  user's  needs. 
Program  acquisition  decisions  must  be  supported  using  analytical  rationale.  Analysis  shall  provide  a 
historical  record  of  the  alternatives  considered  at  each  milestone  decision  point  and  an  audit  trail  of 
decisions  (and  their  rationale)  affecting  weapon  system  requirements.  The  database  should  provide 
software  programs  for  engineering  design,  manufacturing,  and  logistics  processes'  compatible  with 
digital  information,  and  provide  tools  for  incorporating  analyses  and  data  into  requirements'  rationale. 
Standard  documents  should  request  only  the  essential  ne^s  of  the  Government,  describing  the 
supplies  and  services  in  a  manner  that  erKxxirages  maximum  competition.  (>)ntractors  should  develop 
shared  environments  consisting  of  analysis  tools  and  integrated  databases.  Digital  data  deliverables 
should  comply  with  established  CALS  procedures. 

d.  OOD  Manual  (DOOM)  5000.2M,  Defense  Acquisition  Management  Documentation  and  Reports, 
23  February  1991;  This  manual  implements  relevant  portions  of  DODD  5000.1  and  DODI  5000.2.  It 
provides  procedures  and  formats  for  preparing  milestone  documentation,  periodic  in-phase  status 
reports,  and  statutory  certifications. 

e.  Air  Force  Instmction  (AFI)  10-601 ,  Mission  Needs  arxJ  Operational  Requirements  Guidance  and 
Procedures,  16  February  1993:  This  instruction  identifies  official  Air  Force  information  required  for 
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decision  making  and  historical  purposes.  It  provides  the  guidance  used  for  the  information  life  cycle, 
describing  the  creation,  maintenance,  and  disposition  (AFI 37-123,  Mana^ment  of  Records).  It 
identifies  the  activities  used  to  plan,  design,  model,  synchronize,  standardize  arxt  control  Air  Force 
Corporate  data  td  alt  echelons  (DODO  8320. 1 .  Data  Administration,  26  September  1991 .  and  AFI  37- 
150,  Data  Administration  and  Standards  Program).  The  following  items  apply  to  specific  areas; 
paragraph  1.17,  Oocumerdation  Control;  Attachment  4,  MNS  Format;  Attachment  5,  COEA 
Procedures;  and  Attachment  6.  ORD  Procedures. 

f.  AF1 10-602,  Logistics  Support  and  Readiness  Requirements:  (On  order) 

g.  AF1 14-303,  Threat  Support,  Acquisition  Process:  (On  order) 

h.  AF1 16-501,  Control  and  Documentation,  Air  Force  Programs:  (On  order) 

i.  AFI  33-105,  Information  System,  Standard  Programs:  (On  order) 

j.  AFI  37-1,  Information  Management;  (On  order) 

k.  AFI  37-123.  Management  of  Records;  Identifies  the  activities  to  plan,  design,  model, 
synchronizes,  standardize  and  control  Air  Force  Corporate  data  at  all  echelons. 

l.  AFI  37-150,  Data  Administration  and  Standards  Program.  (On  order) 

m.  AFPD  10-6,  Mission  Needs  and  Operational  Requirements.  19  January  1993:  This  directive 
requires  the  implementation  of  the  OOD  5000  series  documents. 

n.  AFPD  37-1,  Information  Management,  5  April  1993:  This  directive  establishes  policy  to 
manage  information  from  its  creation  through  its  disposition.  It  ensures  availability  in  support  of  the  Air 
Force  mission,  while  providing  for  the  public's  right  to  access. 

o.  AFPD  63-1 ,  Acquisition  System:  (On  order) 

p.  AFR  55-43,  Management  Operations,  Test  and  Evakiation,  29  June  1990;  Data  Management 
is  explained  in  paragraph  5-12.  The  test  director  should  ensure  the  plan  for  data  collection  and 
analysis  has  been  implemented  before  testing  begins. 

q.  Military  Handbook  (MIL-HDBK)-59A,  DOD  CALS  Program  Implementation  Guide:  The 
purpose  of  this  military  handbook  is  to  provide  general  information  and  detailed  application  guidance 
for  contractually  implementing  CALS  requirements  in  weapon  system  and  related  maior  equipment 
procurements. 

r.  MIL-HDBK-X499-3,  SE/CM,  Draft.  The  decision  database  will  provide  an  audit  trail  from  initially 
stated  needs  and  requirements  to  the  document  description  of  system  products  and  processes.  The 
repository  of  information  used  and  generated  at  the  appropriate  level  for  the  acquisition  phase  of 
integrated  requirements  and  fknvdowns;  interface  constraints  and  requirements;  functional  and 
performance  requirements;  system  concepts;  preliminary  design  and  configuration  alternatives;  detail 
designs;  verifications;  decision  criteria;  trade  study  assessments;  system,  subsystem,  and  functional 
capability  assessments;  aixl  other  required  documentation. 

s.  MIL-STD'499B,  Systems  Engineering,  Draft:  The  decision  database  may  be  digital,  defined  by 
the  Government,  or  left  open  for  contractor  definition.  MIL-STD-499  encourages  minimizing 
deliverable  data  to  ensure  availability  to  the  government,  traceability,  and  compliance  with  Computer- 
Aided  Acquisition  and  Logistics  Support  (CALS). 

t.  MIL-STD-881B,  Work  Breakdown  Stmcture  (WBS);  This  standard  establishes  criteria  governing 
the  preparation  and  employment  of  work  breakdown  structures.  It  is  used  during  the  acquisition  of 
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designated  deiense  materiel  items.  The  WBS  requirements  established  by  this  standard  applies  to  all 
defense  materiel  items  or  major  modifications. 

u.  MIL-STD-1388-1  A,  LSA,  11  April  1983:  The  goal  of  this  standard  is  to  provide  a  single,  uniform 
approach  by  the  military  services  for  conducting  activities  necessary  to  make  supportability 
recK^icements  an  integral  part  of  system  requirements  and  design.  LSA  documentation  consists  of  all 
data  resulting  from  analysis  tasks  conducted  under  this  starKfard.  It  is  the  primary  source  of  validated 
supportability  data  pertainirrg  to  an  acquisition  program.  The  Chief  of  Logistics  shall  ensure  LSA 
documentation  is  developed  and  maintained  commensurate  with  design,  support,  and  operational 
concept  development.  Information  will  be  updated  in  a  timely  manner  using  test  results,  configuration 
changes,  operational  corKept  changes,  and  support  concept  changes,  during  the  acquisition  process. 

V.  MIL-STD-1388-2B,  DOD  Requirements  for  a  LSAR,  28  March  1991 :  This  standard  improves 
the  cost  effectiveness  of  generation,  maintenance,  and  acquisition.  It  uses  the  technical  data  provided 
in  support  of  the  LSA  program.  Direction  is  provided  for  standardization  of  LSAR.  consolidation  of 
logistics  oriented  technical  information,  and  maximum  use  of  industry  developed  integrated  data 
systems. 

w.  MIL-STD-1840A.  Automated  Interchange  of  Technical  Information,  22  December  1987:  The 
purpose  of  this  document  is  to  standardize  the  digital  interface  between  organizations  or  systems.  It 
provides  guidance  in  the  exchange  of  digital  forms  used  for  technical  information  requirements  of 
logistic  support  weapon  systems,  throughout  their  life  cycle.  This  application  addresses  technical 
information  such  as  training,  maintenance  manuals,  and  their  associated  illustrations.  It  defines 
product  data  for  engineering  drawings  and  specifications  that  are  part  of  the  traditional  technical  data 
packages  used  for  item  acquisition.  This  evolving  product  data  concept  provides  for  transfer  and 
archival  storage  of  the  product  information  necessary  for  these  applications. 

x.  Federal  Information  Processing  Standards  Publication  (FIPS  PUB  161),  Electronic  Data 
Interchange  (EDI),  29  March  1991 :  This  FIPS  PUB  adopts,  with  specific  conditions,  the  families  of 
standards  known  as  XI 2  and  EDIFACT.  It  does  not  mandate  the  implementation  of  EDI  systems  within 
the  Federal  Government;  rather  rt  requires  the  use  of  XI 2  or  EDIFACT,  subject  to  the  specified 
conditions,  when  Federal  departments  or  agencies  implement  EDI  systems. 

y.  ANSI  ASC  XI 2,  Electronic  Data  Interchange  Convention  Guide:  This  draft  standard  contains 
the  format,  and  establishes  the  data  contents  of  the  Project  Cost  Reporting  Transaction  Set  (839)  for 
use  within  the  Electronic  Data  Interchange  environmerrt. 

11.  IMPLEMENTATION  TOOLS: 

a.  Logistics  Support  Analysis  Software  is  available  as  Government  Furnished  Property  (GFP). 

(1)  Submit  your  letter  of  request  to: 

Director  USAMC  Logistic  Support  Activity 
ATTN.:  AMXLC-AL 
Lexington,  KY  4051 1-5101 
AC-606-293-4193  (Mr.  David  Henderson) 

(2)  The  letter  should  contain; 

(a)  Your  request  for  MIL-STD-1388-2A  (Mainframe,  COBOL)  or 

(b)  MIL-STD-1388-2B  (Model  204,  Mainframe.  SQL)  or 

(c)  MIL-STD-1388-2B(386PC). 

b.  CALS:  A  repository  of  information  used  and  generated  at  the  appropriate  level  for  the 
acquisition  phase  of  integrated  requirements  and  flowdowns;  interface  constraints  and  requirements; 
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functional  and  performance  requirements;  system  concept;  preliminary  design  arxl  configuration 
alternatives;  detail  designs;  verifications;  dedsion  criteria;  trade  study  assessments;  system, 
subsystem,  and  functional  capability  assessments;  and  other  required  documentation. 

(a)  MIL-HDBK-59A,  DOO  CALS  Program  Implementation  Guide:  The  purpose  of  this 
military  handbook  is  to  provide  general  information  and  detailed  application  guidance  for  contractually 
in^ementing  CALS  requirements  in  weapon  system  and  related  major  equipment  procurements. 

(b)  MIL-STD-1840A,  Automated  Interchange  of  Technical  Information,  22  December 
1987.  The  purpose  of  this  document  is  to  standardize  the  digital  interface  between  organizations  or 
systems.  It  provides  guidance  in  the  exchange  of  digital  forms  used  for  technical  information 
requirements  of  logistic  support  weapon  systems,  throughout  their  life  cycle.  This  application 
addresses  technical  information  such  as  training,  maintenartce  manuals,  and  their  associated 
illustrations.  It  defines  product  data  for  engineering  drawings  and  specifications  that  are  part  of  the 
traditional  technical  data  packages  used  for  item  acquisition.  This  evolving  product  data  concefM 
provides  for  transfer  and  archival  storage  of  the  product  information  necessary  for  these  applications. 

c.  Systems  and  Logistics  Integration  Capability  (SLIC);  This  is  a  DOD,  Type  III,  validated  micro 
computer  based  LSAR  system  used  to  satisfy  all  MIL-STD-1388-2A  and  2B  requirements  with  total 
independence  from  any  other  hardware  and  software.  (ASC/ALTB,  Kevin  Gum,  DSN  785-8572) 

(a)  SLIC/2A  helps  create  and  manage  all  MIL-STD-1388-2A  LSAR  data  and  reports.  It 
produces  all  the  standard  MIL-STD-1388-2A  reports  and  provides  near  instant  response  to  ad  hoc 
information  queries. 

(b)  SLIC/2B  helps  create  and  manage  all  MIL'STD-1388-2B  LSAR  data  and  reports.  It  will 
produce  all  the  standard  MIL-STD-1388-2B  reports  and  provide  near  instant  response  to  ad  hoc 
information  queries. 

d.  Aerospace  Stmcture  Information  and  Analysis  Center  (ASIAC):  ASIAC  provides  the  aerospace 
structure's  community  with  a  single  source  for  structure's  information  and  quick  response  analysis 
capability.  It  is  responsible  for  the  collection,  evaluation,  and  dissemination  of  scientific  and  technical 
data  that  is  applicable  to  all  aspects  of  structures,  including  design,  analysis,  and  performance,  with 
emphasis  on  aircraft,  spacecraft,  and  missile  structures.  The  quick  response  analysis  capability 
applies  to  areas  of  static  and  dynamic  analysis,  structural  optimization.  Computer  Aided  Design 
(CAD)/Computer  Aided  Manufacturing  (CAM)/Computer  Aided  Engineering  (CAE)  technology, 
preliminary  structural  design,  vulnerability,  damage  tolerance,  loads  and  temperature  interaction, 
acoustic  and  vibration  loads,  damping  technology,  electronic  management  of  information  and  data, 
and  aeroelasticity.  ASIAC  also  maintains  a  secure  on-line  terminal  dedicated  to  the  Defense 
Technical  Information  Center  (DTIC)  database,  which  is  connected  to  the  Defense  RDT&E  on-line 
service  (DROLS).  It  uses  more  than  60  databases  to  complete  literature  searches.  (WL/FIBA/ ASIAC, 
Gordon  Negaard,  DSN  785-6688) 

e.  Supportability  Investment  Decision  Analysis  Center  (SIDAC):  SIDAC  is  an  informatbn  analysis 
center  dedicated  to  helping  customers  throughout  the  Department  of  Defense  make  wise  investment 
decisions  in  the  arena  of  weapon  system  supportability.  SIDAC  assists  engineers,  logisticians,  and 
managers  through  the  performance  of  modeling,  analysis,  and  the  conveyance  of  information  in  the 
areas  of  logistics  research  and  development,  technology  transitioiVinserlion^ransfer,  and  logistics 
support.  Customers  can  use  SIDAC  to  research  supportability  information,  request  bibliographies,  or 
ask  quick-response  technical  questions.  Customers  can  purchase  various  data  books,  critical  reviews, 
and  state-of-the-art  reports  for  a  nominal  fee;  request  model  software,  documentation,  and  training; 
use  SIDAC  to  perfomn  special  tasks  and  analyses;  and  use  SIDAC  to  host  and  run  conferences, 
symposia  and  training  workshops.  SIDAC  has  a  model  repository  of  eleven  supportability-based 
models  and  access  to  fifteen  database  systems.  (HQ  AFMC/CIXR,  Mary  Grathwohl,  257-5284) 
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f.  Survtvability/Vulnerability  Information  Analysis  Center  (SURVIAC):  SURVIAC  is  a  DOD- 
sponsored  center  operated  by  BOOZ-ALLEN  &  HAMILTON  Incorporated.  They  provide  a  one-stop 
resource  for  all  aspects  of  non-nuclear  survivability,  lethality,  and  mission  effectiveness.  Their  goal  is 
to  increase  the  knowledge  and  productivity  of  scientists,  engineers,  analysts,  and  program  managers 
engaged  in  weapon  system  research,  development,  acquisition,  and  support.  They  can  be  of  particular 
assistance  in  addressing  the  challenges  of  enhancing  system  survivabMily  and  lethality. 
(WL/FIVS/SURVIAC,  Donna  Egner,  DSN  785-4840) 

g.  Requirements'  Analysis  Process  in  Design  (RAPID):  RAPID  is  a  research  and  development 
program  sponsored  by  Armstrong  Laboratory.  It  emphasizes  application  of  computer-based 
technology  to  weapon  system  requirement's  management,  rationale  capture,  and  program 
documentation  management.  (J.  Peasant.  Armstrong  Laboratory,  DSN  785-8502). 

12.  PLANNING  GUIDANCE:  Provide  information  useful  for  ^ivity  planning  purposes. 

a.  DURATION :  It  will  start  with  a  request  for  assistance  from  the  customer  to  provide  analysis 
support.  The  initial  request  should  irxilude  the  DPG,  MAA,  and  the  MNA.  Use  seized  groutxf  rules 
and  assumptions  for  the  analysis.  Include  the  types  of  rrodels  used  in  the  database  or  the  results  and 
rationale  for  any  decisions  made  from  the  analysis.  Update  the  database  in  a  timely  manner, 
throughout  the  acquisition  life  cycle. 

b.  CONSTRAINTS: 

(t)  Identify  computer  resource  constraints  (examples  include  computer  language,  data  base, 
architecture,  or  inter-operability  constraints). 

(2)  Database  capacity  (identify  spare  memory  and  throughput  requirements,  computer 
memory  growth  requirements,  software  partitioning  arid  modular  design  requirements  such  as  software 
module  size  (e.g.,  no  greater  than  100  lines  of  code). 

(3)  Additional  constraints  may  include:  Authorized  access  capabilities,  security  restrictions, 
training,  funds,  and  management. 

C.  RESOURCES: 

(1 )  Provide  a  work  area  for  the  classified  database  storage,  including  personnel  office  space 
and  supplies.  Grant  security  access  to  required  participants,  including  contractors. 

(2)  Computer  hardware  and  software  programs  will  be  required  that  provide  external  data 
access;  information  storage,  analysis,  and  retrieval;  documentation  linkage;  documentation 
management;  analytical  modeling;  and  Program  Management  capabilities. 

(3)  Manpower  resources  will  be  required  to  maintain  and  control  access  to  the  database. 

d.  LESSONS  LEARNED: 

(1)  #  1264,  Target  Operating  Environment;  A  lack  of  defined  target  operating  environments 
will  affect  the  AFMC's  Multi-program  architecture  and  complex  integration  factors.  This  will  greatly 
increase  the  risks  of  successfully  managing  the  development  of  the  Logistics  Management  System. 
The  architecture  should  include  mandatory  standards  and  policies  for  magnetic  data  storage,  operating 
systems  software,  information  processing  center  management  software,  database  management 
system  software  and  query  language,  security  management  software,  and  application  code  naming 
conventions.  (AFMC/CITA,  Peter  Petrusch,  DSN  787-6287) 

(2)  #1344,  Schedule  Plan  For  A  Source  Selection:  Develop  a  detailed  plan  for  the  execution 
of  source  selection  that  will  aid  the  flow  of  data  and  provide  expedient  changes  to  contingencies.  All 
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data  was  computerized  on  an  IBM  program  called  ’Microsoft  Project  ‘  The  data  was  placed  in  a 
network  to  define  the  internal  relationships  of  activities  and  resources.  A  Gantt  chart  was  used  to 
provide  schedule  suspense  dates  and  senre  as  a  tracking  tool.  By  computerizing  the  data  base  ’what- 
if’  scenario's  could  be  evakiated  based  on  unknown  contingencies  (i.e.,  slip  of  data  reviews, 
modifications  to  the  proposals,  personnel  conflicts  or  absences.)  (ASC/CYX,  Tom  Thorpe,  DSN  785- 
7614) 


(3)  #1418,  Internal  Financial  Management;  Funds  for  intemationat  programs  is  not  US 
Government  appropriated  funds  and  does  not  expire.  Failure  to  follow  sound  financial  management 
can  result  in  program  execution  shortfalls.  The  aircraft's  international  finance  division  has  developed 
and  on-line  data  system  to  track  a  multitude  of  data  elements  including  cost  allocation  for  Engineering 
Change  Proposals  (ECP's).  The  FACTS  database  requires  a  closer  working  relationship  between  the 
program  managers,  Confi^ration  Change  Board  (CCB),  and  financial  managers.  (ASC/YPTI,  Cindy 
Caughey,  DSN  785-5433) 

(4)  #1888,  Program  Managers;  Develop  a  process  to  ensure  ’best  practices’  are  entered  into 
the  Acquisition  Database.  Lessons  learned  are  evaluated  by  the  program  director  for  applicability  and 
usefulness.  (AFMC/XRMC,  Dave  Gregorovic,  257-2030) 

(5)  #  1982,  Program  Directors;  Enhanced  quality  and  quantity  of  information  on  the  AFAM 
database.  Improvements  include  additional  lessons  learned  and  best  practices,  updated  references, 
increased  number  of  tools  such  as  software  programs,  document  templates,  samples,  and  courses. 
(ASC/CYM,  Pat  Hogt,  DSN  785-0423) 

(6)  #  9020  (TechTip  89021),  Hardness  Surveillance  Test  Systems  (PHSTS);  The  PHSTS, 
(pronounced  ’fasts’)  is  a  fully  automated  data  acquisition  system,  designed  to  test  a  weapon’s 
vulnerability  for  Nuclear  Electromagnetic  Pulse  (EMP).  The  database  was  developed  to  fully 
document  all  test  phases  to  ensure  repeatability  and  traceability.  The  complete  processing  capability 

9  provides  meaningful  information  several  minutes  after  the  data  is  acquired.  Although  PHSTS  is  quite 
large  and  rec^ires  engineering  support,  the  PHSTS  operation  is  continuously  being  upgraded  with 
technician  transparency  in  mind.  (OCALC/TIESW,  Randy  Vu,  DSN  336-4430) 

(7)  #  9063,  Air  Force  Electronic  Combat  Office  (AFECO  (This  organization  has  been  renamed 
"Electronic  Combat  SPO’]);  AFECO  identifies  commonalty  opportunities  to  the  Air  Staff  for  PMD 
revision/direction,  and  builds/maintains  the  Electronic  Combat  (EC)  program  historical  information 
database  for  all  USAF  EC  programs.  They  distribute  the  annual  funding  between  studies  and 
analyses,  EC  test  process  development,  mission-level  simulation,  and  EC  database  development. 
(ASC/RWXA,  MS  Schraer,  DSN  785-2108) 

(8)  #9115,  ASIAC  provides  the  aerospace  structure's  community  with  a  single  source  for 
structure's  information  and  quick  response  analysis  capability.  It  is  responsible  for  the  collection, 
evaluation,  and  dissemination  of  scientific  and  technical  data  that  is  applicable  to  all  aspects  of 
structures,  including  design,  analysis,  and  performance,  with  emphasis  on  aircraft,  spacecraft,  and 
missile  structures.  The  quick  response  analysis  capability  applies  to  areas  of  static  and  dynamic 
analysis,  structural  optimization,  Computer  Aided  Design  (CAD)/Computer  Aided  Manufacturing 
(CAM)/Computer  Aided  Engineering  (CAE)  technology,  preliminary  stoictural  design,  vulnerability, 
damage  tolerance,  loads  and  temperature  interaction,  acoustic  and  vibration  loads,  damping 
technology,  electronic  management  of  information  and  data,  and  aeroelasticKy.  ASIAC  also  maintains 
a  secure  on-line  terminal  dedicated  to  the  Defense  Technical  Information  Center  (DTIC)  database, 
which  is  connected  to  the  Defense  RDT&E  On-Line  Service  (DROLS).  It  uses  more  than  60  databases 
to  complete  literature  searches.  (WL/FIBA/ASIAC,  Gordon  Negaard,  DSN  785-6688) 

(9)  #9116  (TechTap  8905),  Reliability  Analysis  Center  (RAC);  RAC  maintains  an  extensive 
database  containing  actual  field  reliability  performance  data  on  thousands  of  components.  It  has 
access  to  military  databases  such  as  MODAS,  MIMMS,  SCE,  3M,  as  well  as  many  corporate  warranty 
databases  not  available  to  the  general  public.  The  document  center  includes  an  automated 
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bibliographic  capability,  permitting  rapid  identification  of  documents  on  any  reliability  topic.  (HI 
Research  lnst«t  <te,  Michael  J.  Rossi,  DSN  587-4151) 

e.  BEST  PRACTICES: 

(1)  Use  MIL-HDBK-59A,  DOD  CALS  Program  Implementation  Guide,  and  MIL-STD-1840A, 
Automated  Interchange  of  Technical  Information  to  control  data  storage  with  frequent  backups  to  avoid 
the  loss  of  data. 

(2)  Devel^  an  Integrated  database  using  Information  Integration  Technology,  Advanced 
Technology  Transition  Dermnstration  (ATTD)  Investnrent,  Strategy  Sheet  number  AT-HS-243, 
February  1993. 

(3)  In^ement  hardware  and  software  architecture  to  exploit  open  system  stairxfards  being 
developed  in  the  computer  industry.  This  will  facilitate  inter-operability,  extendibility,  and  upgradability 
of  the  database. 

f.  TRAPS. 

(1)  Non-compatible  CALS  systems  have  problems  with  non-standard  terminology  used  to  file 
or  retrieve  data. 
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ELEMENT:  D17,  TBS  0.1.9.6  (IFC  93-3) 

ELEMENT  TITLE:  Update  Mission  Area  Development  Plans 
ELEMENT  OWNER(S):  Technical  Planning  Integrated  Product  Teams  (TPIPTs) 

ELEMENT  STAKEHOLDER(S): 

a.  Operating  Command's 

b.  SPD's 

c.  Laboratories 

d.  PC/ALC  Development  Planners 

e.  Technology  Transition  Office  (TTO) 

f.  Industry 

g.  SAF/AQT 

REQUIREMENT: 

a.  AFMC  Policy  Letter  (Draft),  Aug  1992  -  overview  and  charter  for  the  implementation  of 

TPIPTs: 

b.  ASC  TPIPT  Charter  (Draft).  Apr  1993  -  describes  purpose,  objectives  and  function  of  the 
TPIPTs  at  ASC,  similar  charters  being  developed  at  other  Product  Centers; 

c.  SAF/AQT  PMD,  Uncertain  date  -  references  guidance  to  be  provided  to  Labs.. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  Provide  a  comprehensive  reference  to  the  status  of  activities  (including  identified 
deficiencies  and  assessments)  that  are  being  conducted  across  an  operating  MAJCOM  and  the 
commands  that  are  providing  support. 

b.  Objective(s); 

(1)  Evaluate  and  compile  mission  needs,  evolving  requirements,  system  upgrades  and 
alternative  concepts,  technologies  and  operational  capabilities  for  military  assets. 

(2)  Develop  descriptions  of  functional  areas  that  are  in  support  of  potential 
developments  for  operational  capabilities. 

(3)  Identify  representative  system  concepts  that  are  potential  alternatives  for  solving 
mission  deficiencies  and  that  can  be  evaluated  through  technology  sensitivities. 

7.  DESCRIPTION:  The  Mission  Area  Development  Plans  (MADP)  are  documents  generated  by  the 
Technical  Planning  Integrated  Product  Teams  (TPIPTs)  at  ASC.  The  MADPs  are  intended  to  be  a 
standard  reference  for  each  of  the  operating  MAJCOMs  (i.e.  ACC,  AMC,  etc)  and  contain  current 
information  on  subject  areas  such  as  missions,  force  composition  and  structure,  threats  and  scenario(s) 
status,  mission  ne^,  technology  base,  and  assessments  of  activities  and  plans.  Annual  updates  are 
planned  for  each  of  the  documents,  in  order  to  provide  the  latest  status  in  the  areas  previously 
mentioned.  The  ASC  TPIPTs  are  a  network  of  key  representatives  from  operating  MAJCOMs,  (ACC/DR, 
AFSOC/XP,  AMC/XR,  etc),  development  planners  (XR,  YX,  etc),  system  program  offices  (SD,  YJ,  YA, 
etc),  Wright  Laboratory  (XP,  MT,  etc),  intdiigence  (FASTC)  and  product  groups  (SM.  etc).  The  TPIPTs 
at  ASC.  being  aligned  with  the  ojserating  MAJCOMs,  also  have  interfaces  (i.e.  members)  established 
with  functional  organizations  and  TPIPTs  located  at  other  product  centers.  Laboratories,  air  logistics 
centers  and  test  centers  (PC/ALC/TC)  across  Air  Force  Materiel  Command  (AFMC).  Examples  of  these 
interfaces  are  WR/LU  at  Robins  AFB,  Rome  Lab  (XPT),  the  C3I  TPIPT  at  ESC,  the  Crew  Systems 
TPIPT  at  HSC,  and  the  Theater  Missile  Defense  TPIPT  at  SMC. 
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One  of  the  functions  of  the  TPIPTs  is  to  recommend  and/or  rmnitor  assessments  of  mission 
deficiencies  (C12)  that  are  identified  through  the  MAJCOM's  Mission  Need  Analysis  (MNA)  (C3). 

Periodic  feedback  from  these  deficiency  assessments  provide  the  type  of  information  that  is  evaluated 
and  incorporated  into  the  MADPs  (09  &  01 5).  This  information  covers  areas  such  as  concept 
altematives,  enabling  technologies,  threat  descriptions,  etc.  The  MAOP  also  becomes  a  useful  reference 
to  sources  for  documentation  of  methodologies  used  to  generate  mission  needs,  identified  mission  needs 
(MNSs),  and  groundrules  used  in  setup  and  execution  of  the  various  assessments.  At  any  given  point 
(during  the  calendar  year),  the  updates  could  reference  efforts  that  are  just  completed,  in  progress,  or 
just  being  initiated.  There  is  no  master  schedule  that  orchestrates  these  broad  types  of  activities. 

Most  of  the  ASC  TPIPTs  hold  individual,  quarterly  working  meetings  of  core  members.  They 
assess  and  review  a  variety  of  activities  across  the  MAJCOM  and  supporting  commands  or 
organizations.  Thus,  each  project  team  that  is  addressing  identified  MAJCOM  needs  should:  have 
sponsorship  from  one  (or  more)  of  the  AFMC  TPIPTs:  provide  status  reports  during  the  quarterly 
sessions;  and  be  referenced  in  the  MADP  as  appropriate. 

8.  ENTRANCeEXrr  CRITERIA: 

a.  Entrance;  Errter  at  any  quarterly  status/review  meeting  of  a  TPIPT  with  preliminary  concept 
approaches  that  would  support  the  development  of  Mission  Need  Statement(s). 

b.  Exit;  Ends  with  the  annual  production  (September)  &  distribution  of  the  Mission  Area 
Development  Plan  (MADP). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs; 

(1 )  Prior  years'  MADP  from  TPIPTS 

(2)  Preliminary  System  Concept  Options  (SCO)  (D9&D15) 

(3)  MAJCOMs  Preliminary  MNS  (C12);  data  for  the  mission(s),  their  objectives  and 
generic  capabilities  that  were  referenced,  also  the  relative  priority  and  timing  of  the  need;  operational 
constraints  and  environments  of  the  mission(s)  being  evaluated. 

(4)  Results  of  the  Mission  Needs  Analysis  (MNA)  (C3). 

b.  Outputs; 

(1 )  Feedback  to  project(s)  Draft  MNS  (C12);  refinements  for  material  alternatives  and 
operational  constraints; 

(2)  Preliminary  or  interim  guidance  for  technology  needs  to  be  provided  to  appropriate 
Laboratories  (D18).  The  TPIPTs  publish  an  annual  Technology  Investment  Recommendation  Report 
(TIRR)  along  with  the  MADP. 

10.  KEY  REFERENCES: 

a.  AFMC  Policy  for  the  TPIPTs  (Draft),  1992  -  document  being  coordinated  by  AFMC/XRX. 

b.  Guide  to  Technology  Master  Process,  AFMC/DPUL,  30  Oct.  92  -  describes  the  areas  of 
interface  between  the  Technology  evolution  and  TPIPT  developments. 

c.  Policy  Letter,  Gen  Ronald  Yates,  Feb  1992  -  describes  the  AFMC  Commander's  vision  for 
providing  integrated  support  to  the  MAJCOMs;  refers  to  Technical  Oversight  Centers  (TOCs),  which 
were  precursors  to  TPIPTs,  as  a  means  of  achieving  this  support. 

11.  IMPLEMENTATION  TOOLS: 

a.  TPIPT  process  guidance;  ASC/XRS  and  AFMC/XRX;  Charter,  policy  and  guidance. 
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12.  PLANNING  GUIDANCE:  The  AFMC  TPIPTs  cover  more  than  one  mission  artd  functional  area  and 
get  the  stakeholders  involved  to  work  their  areas  of  responsibility.  This  is  an  important  step  in  the 
compilation  of  essential  development  and  acquisition  information.  With  the  TPIPTS  just  being  formed, 
this  multi-organizational  network  will  continue  evolving  over  the  next  couple  of  years. 


a.  DURATION:  Updates  to  the  MADP  commence  1 1  months  prior  to  planned  publication:  in 
other  words,  right  after  the  annual  publication  each  Sefi^ember;  it  is  a  continuing  process.  Efforts  that 
are  addressing  individual  deficiencies  are  periodically  exchanging  results  of  their  activities  through  the 
TPIPTs. 

b.  CONSTRAINTS:  The  quantity,  quality  and  completeness  of  available  data  depends  upon  the 
rumber  and  extent  of  progress  of  various  project  teams  that  are  evaluating  mission  deficiencies. 
Schedules  of  these  various  project  teams  that  are  identifying  or  addressing  mission  area  deficiencies  are 
not  necessarily  coordinated. 

c.  RESOURCES:  Requires  active  participation  of  the  TPIPT  stakeholders  and  focal  points  from 
major  project  teams;  product  center  XRs  are  OPRs. 

d.  LESSONS  LEARNED:  This  is  in  it's  infancy,  but; 

(1)  Maintain  strong  presence  from  the  Laboratories,  SPDs  and  Lead  MAJCOMs. 

(2)  Keep  Hq  and  Air  Staff  in  the  loop;  he^s  prevent  "stumbles",  i.e.  delays  in  the 
planning  and  programming  of  development  efforts. 

(3)  Continuously  cross-check  with  the  stakeholders  and  other  TPIPTs;  quarterly  status 
and  assessment  meetings  are  normally  conducted  by  each  TPIPT; 

(4)  Communication  is  an  important  factor;  do  not  let  it  become  a  big  problem  by  letting  it 
lag  because  of  parochial  interests  (paradigms?). 

e.  BEST  PRACTICES:  Maintain  cognizance  of  the  usefulness  that  any  of  the  development 
activities  could  add  to  the  overall  mission  area  evaluations  and  plans.  Many  separate  activities  are 
being  conducted  at  the  same  time  across  the  stakeholders'  organizations.  Project  and  program  (i.e. 
MADP,  ATTD  reports,  SENTAR  evaluations,  etc.)  documentation  is  an  important  but  often  overlooked 
requirement. 

f.  TRAPS:  Procrastination;  it  is  almost  impossible  to  start  this  activity  a  few  months  prior  to 
publication  and  expect  to  have  a  quality  document. 
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1.  ELEMENT:  DIB.  TBS  0.1. 9.7  (IFC  93-3) 

2.  ELEMENT  TITLE:  Prepare  Technology  Guidance 

3.  ELEMENT  OWNER(S):  Technical  Planning  Integrated  Product  Teams  (TPIPTs) 

4.  ELEMENT  STAKEHOLDER(S): 

a.  ASC/XR 

b.  Laboratories 

c.  SPDs 

d.  PC/ALCs 

e.  Operating  Commands 

f.  Technology  Transition  Office  (TTO) 

g.  Industry 

h.  SAF/AQT 

5.  REQUIREMENT: 

a.  AFMC  Policy  Letter  (Draft)  -  establishes  policy  and  charter  for  TPIPT  functions. 

b.  ASC/XR  TPIPT  Charter  (Draft),  May  93  -  outlines  mission  and  function  of  the  mission- 
oriented  TPIPTs  at  ASC. 

c.  SAF/AQT  PMD  -  reference  to  guidance  to  be  provided  to  Labs. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  Purpose  is  to  provide  guidance  to  the  laboratories  in  planning  the  development, 
transition,  and  insertion  of  technologies  for  system  upgrades,  new  or  modified  systems,  and  emerging 
concepts. 

b.  Objective(s): 

(1)  Identify  the  Critical  Mission  Needs  (CMN)  that  will  help  focus  technology 

developments. 

(2)  Describe  functional  areas  of  potential  technology  developments. 

(3)  Present  notional  or  representative  future  systems  with  a  description  of  the  key 
technology  areas. 

7.  DESCRIPTION:  This  activity  involves  the  collection  of  identified  technology  needs  from  both  mission 
and  functional  Technical  Planning  Integrated  Product  Teams  (TPIPTs)  and  related  development 
analyses  (Cl  3,  D9).  This  infomr»ik"i  is  collected,  compiled,  and  reviewed  under  broad  technology  areas 
by  each  of  the  TPIPTs  across  AFMC  (D17).  With  this  information  being  provided  as  guidarv^e,  the 
laboratories  can  identify  technology  n^s  and  performance  parameters  for  emerging  technologies  and 
further  research  in  their  broad  technology  araa.  that  will  support  the  cap^lity  needs  of  the  MAJCOMs. 
This  becomes  the  starting  point  of  the  Integrated  Weapon  System  Planning  (IWSP)  for  Technology  Base 
arxf  Technology  Maturity.  It  also  helps  establish  the  grourxf  work  for  the  Technolo^  Transition  Martager 
to  start  and/or  continue  work  on  Technology  Transition  Plans  and  applicable  Advanced  Technology 
Transition  Demonstration  Programs  (ATTD's)  and  Critical  Experiments  (CEs). 

The  activity  is  currently  an  annual  exchange  with  the  Laboratories,  covering  several  sessions  thoughout 
the  year  (see  prior  year's  TIRR).  Plans  are  being  considered  for  also  including  industry  and  other 
government  laboratories  in  this  exchange.  It  precedes  the  Hq  A^MC  preparations  of  an  annual  strategic 
technology  investment  plan  (STIP)  as  outlined  in  the  Technology  Master  Plan  (TMP). 
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8.  ENTRANCEyEXIT  CRITERIA: 


a.  Entrance:  Enter  alter  updates  to  the  Mission  Area  Development  Plans  (MAOPs)  have 
determined  a  direction  or  focus  for  technology. 


b.  Exit:  Ends  with  the  production  &  distribution  of  the  annual  Techrioiogy  Investment 
Recommendation  Report  (TIRR). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1 )  Prior  years'  TIRR  from  TPIPTS  (D18). 

(2)  Preliminary  System  Concept  Options  (SCO)  (09). 

(3)  Updated  Mission  Area  Development  Plans  (D17). 

(4)  MAJCOMs  MNS  Staffing  and  Coordination  (C13):  operational  constraints  and 
environmental  conditions;  description  of  the  generic  mission(s)  that  resulted  in  the  need  being  identified. 


b.  Outputs:  The  output  of  this  activity  is  guidance  on  the  technology  needs  that  are  provided  to 
appropriate  Latoratories  (D30).  The  TPIPTs  publish  an  annual  Technology  Investment 
Recommendation  Report  (TIRR)  and  a  MADP  that  describes  15  to  20  years  of  planned  Air  Force 
developments  across  the  Laboratories,  SPDs/PGMs/MGMs,  and  MAXOMs. 

10.  KEY  REFERENCES: 

a.  Guide  to  Technology  Master  Process,  AFMC/DPUL,  30  Oct.  92  •  describes  the  areas  of 
interface  between  the  Techrul^  evolution  and  TPIPT  developments. 

b  AFMC  Policy  for  the  TPIPTs  -  Draft  document  being  coordinated  by  AFMC/XRX. 

c.  Policy  Letter,  Gen  Ronald  Yates,  Feb  1992  •  describes  the  AFMC  Commander’s  vision  for 
providing  integrated  support  to  the  MAJCOMs. 

11.  IMPLEMENTATION  TOOLS: 

a.  TPIPT  process  guidance,  currently  being  documented  in  ASC/XRS. 

12.  PLANNING  GUIDANCE:  This  technology  guidance  from  the  TPIPTs  covers  more  than  one  mission 
area  and  gets  the  stakeholders  involved  to  work  their  areas  of  responsibility.  This  is  an  important 
information  exchange.  Because  the  TPIPTS  are  just  being  formed  and  the  TMP  is  changing,  this  wiH 
probably  require  some  fine  tuning  over  the  next  couple  of  years. 

a.  DURATION:  Typically  requires  1  week  to  finalize  documentation,  2  to  3  months  of 
preparation  activities,  and  continual  interfaces  and  exchanges  maintained  through  the  TPIPT-level 
activities.  There  are  several  individual  events  that  contribute  to  the  overall  preparation: 

(1)  MAJCOM  Requirements  Review;  2-3  day  annual  event;  March  timeframe. 

(2)  Spring  Technology  Reviews;  1-3  day  event  at  each  AF  Laboratory;  highlights  6-3 
and  some  6-2  development;  May-June  timeframe. 

(3)  Technology  Area  Plan  Reviews:  MAJCOMs,  Product  Center  XRs,  TPIPTS  and  SAB 
critiques  of  ATTDs  and  plans;  May-Aug  timeframe. 

(4)  XR  Exchange:  between  Product  center  and  Laboratory;  focus  on  establishing  Critical 
Mission  Needs;  2-3  Days  over  2-week  period;  Jun-July  timeframe. 


Nov  93 


« 


b.  CONSTRAINTS:  The  quantity,  quality  and  completeness  of  available  data  deper^  upon  the 
number  and  extent  of  progress  of  various  project  teams  that  are  evaluating  mission  deficierK:ies. 
Schedules  of  these  various  project  teams  that  are  addressing  kjentilied  mission  area  deficiencies  are  not 
necessarily  coordinated. 

c.  RESOURCES:  Requires  active  participation  of  the  TPIPT  stakeholders  and  focal  points  from 
major  project  teams;  product  center  XRs  are  OPRs. 

d.  LESSONS  LEARNED:  The  publication  of  the  TIRR  is  a  single  event,  but  its  development 
requires  year-round,  active  participation  by  TPIPT  stakeholders.  This  is  particularly  important  for  the 
kinctional  areas  and  their  technical  disciplirres.  Sources  of  useful  information  include: 

(1)  MAJCOM  existing  MNS  arxl  evolving  MNA. 

(2)  Preliminary  Concepts  identified  during  draft  MNS. 

(3)  Preferred  alternatives  selected  for  Milestone  I. 

(4)  Sustainment  needs  from  System  Product  Directors. 

(5)  Techrtology  thrusts,  including  6-2  funded  efforts. 

e.  BEST  PRACTICES:  Summarizing  across  ail  mission  and  functional  areas  is  highly 
important.  It  is  essential  to  maintain  an  AF-wide  perspective  in  feedback/guidance  to  the  Labs. 

f.  TRAPS:  Waiting  too  long  before  starting  the  framework  and  draft  content  of  laboratory 
guidance.  It  is  almost  impossible  to  start  this  activity  a  couple  of  months  prior  to  the  TIRR  publication. 
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1.  ELEMENT:  D20A,  TBS  1.1 .1.2  (IFC  93-3) 

2.  ELEMENT  UTLE:  Develop  Draft  Phase  0  Plans  (AFMC  Centers) 

3.  ELEIKKNT  OWNER(S):  Asslj^ed  AFMC  Product  Center  (PC)  and/or  Air  Logistics  Center  (ALC) 
Protect  Team.  Typically.  Phase  0  systems  acquisition  activities  wiH  be  assigned  to  a  PC.  wkh  very 
limited  ALC  supp^  through  milestone  I.  ALC  assignments  wi  be  more  penrasive  with  development 
activities  associated  with  modifications  to  fielded  systems. 

4.  ELEMENT  STAKEHOLOER(S): 

Air  Staff  (USAF/XOR.  SAF/AQX) 

-  Operating  Command(s) 

-  Air  Force  Materiel  Command  (AFMC/CC.  XR) 

■  AFMC  Product  arKf  Air  Logistics  Centers  (PCs/ALCs) 

5.  REQUIREMENT: 

-  AF  Regulation  800-1 . 16  Feb  90.  '/Vir  Force  Acquisition  System."  paragraph  5.c,  identifies  the 
acquisition  management  responsibilities  of  Air  Force  acquisition  managers. 

-  AF  Instruction  10-601 . 1  Oct  92.  "Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures."  Attachment  2.  identifies  the  Major  Commarid  (MAJCOM)  and  Reid  Operating  Agency 
(FOA)  pre-Milestone  I  responsibilities. 

6.  PURPOSE/OBJECTIVES: 

^  a.  Purpose:  Support  the  lead  MAJCOM  to  develop  the  Air  Force  preliminary  Phase  0  planning 

position.  For  Air  Force-led  premilestone  I  activities,  the  lead  MAJCOM  is  typically  an  operating 
command. 

b.  Objective(s):  To  identify  and  document  the  following  planning  information  to  support  the  lead 
MAJCOM  completion  of  preliminary  Phase  0  planning: 

-  Phase  0  constraints  and  assumptions; 

■  Alternative  strategies  and  organization  for  completing  Phase  0  objectives; 

-  Identification  of  all  tasks  required  to  complete  Phase  0  objectives; 

-  Schedule  estimates  with  exit  criteria  for  corr^leting  all  Phase  0  objectives; 

-  Estimates  of  required  resources  needed  to  complete  Phase  0  objectives; 

-  Content  recommendations  for  the  Acquisition  Decision  Memorandum  (ADM)  and 
Program  Management  Directive  (PMD)  (as  required). 

7.  DESCRIPTION:  After  the  Operating  Command  has  identified  an  operational  need  that  cannot  be  met 
through  nonmateriel  means,  a  Mission  Need  Statement  (MNS)  win  be  written,  and  the  Operating 
(Command  wilt  indicate  a  need  to  proceed  to  a  milestone  0  decision.  At  this  point  the  lead  MAJCOM 
should  initiate  planning  activities  to  identify  the  desired  participants,  strategies,  organizational  structure 
and  relationsh^,  and  associated  costs  and  manpower  required  for  Phase  0.  To  be  useful,  the  Phase  0 
planning  activities  must  be  a  coordinated  effort  between  all  of  the  government  and  industry  (to  the 
extent  possible)  organizations  expected  to  implement  the  plans  when  approved. 

AFMC  PCs  and  ALCs  are  major  stakeholders  in  all  potential  Air  Force  acquisition  programs  and 
will  typically  provide  the  lead  MAJCOM  with  the  majority  of  the  Phase  0  planning  information  to  support 
these  programs.  The  Integrated  Weapon  System  Management  (IWSM)  philosophy  and  principles 
discussed  in  AFMCP  800-60  should  be  used  as  overall  guidance  for  establishing  a  quality  team  and  plan 
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tor  the  PC/ALC  Phase  0  activities.  One  ot  the  principles  that  IWSM  directs  is  the  creation  of  integrated 
product  team(s)  (IPTs)  to  execute  the  Phase  0  activities.  The  make-up  of  the  IPT(s)  should  irx^iude 
personnel  from  each  of  the  organizations  and  technical  d^ipltnes  critical  to  achieving  the  Phase  0 
objectives.  For  Phase  0  activities  this  typically  will  include  resources  from  program  management, 
program  development,  development  planning,  engineering,  logistics,  test,  financial  management, 
contracting,  studies  and  analysis,  the  laboratories,  industry  (if  appropriate),  and  other  organizations  as 
required.  The  organization  responsible  tor  program  development  within  the  PC/ALC  will  typically  be 
assigned  the  lead  for  Phase  0  and  should  typically  lead  the  IPT  planning  activities.  Within  most  AFMC 
PCs/ALCs,  the  XR  community  is  the  responsible  organization  for  premilestone  I  activities.  At  ASC. 
however,  YX  would  be  responsible  tor  Phase  0  planning  and  execution. 

The  IPT(s)  should  work  directly  with  the  lead  MAJCOM  to  identify  critical  planning  information 
like  the  purpose  arto  objectives  of  the  Phase  0  activities,  the  role  of  the  PC/ALC,  and  any  constraints  and 
assumptions  the  lead  MAJCOM  wants  to  apply  to  the  PC/ALC  activities,  before  attempting  to  plan  their 
activities  in  any  detail.  The  PC/ALC  Phase  0  plans  resulting  from  this  activity  must  meet  the  lead 
MAJCOM  stated  objectives  given  any  constraints  or  assumptions  they  may  have  applied.  It  is  important 
each  IPT  leader  keep  their  IPT  focused  on  this  point  to  ensure  each  objective  is  adequately  accounted 
for. 


Having  identified  their  purpose  and  objectives,  the  IPT  needs  to  determine  its  strategy  tor 
accomplishing  their  assigned  Phase  0  objectives.  The  strategy  should  discuss  the  overall  business  and 
technical  approaches/processes  to  be  used  by  the  PC/ALC  to  accomplish  the  effectives.  It  should 
specifically  bound  the  scope  of  the  work  to  be  performed  and  identify  the  major  activities  to  be 
completed  to  satisfy  all  assigned  objectives.  Analytical  methodologies  and  models  to  be  used  should  be 
considered  (see  D20B).  Potential  risks  should  be  identified.  Pollution  prevention  and  other 
environmental  artd  political  concerns  must  be  addressed.  Known  constraints  such  as  funding, 
manpower,  schedule,  etc.,  must  also  be  considered  for  their  impacts  on  the  strategy.  The  IPT  should 
develop  several  different  strategy  approaches,  and  then  weigh  the  pros  and  cons  of  each  approach 
before  settling  on  a  preferred  strategy.  Depending  on  the  significance  of  the  Phase  0  activity,  the  IPT 
may  want  (or  may  be  required)  to  obtain  an  independent  review  of  their  various  strategy  approaches 
before  choosing  a  preferred  direction.  Typically,  independent  reviews  are  accomplished  through  the  use 
of  acquisition  strategy  panels  (ASPs).  See  D61  for  more  information  regarding  the  ASP. 

Hand-in-hand  with  developing  the  strategy,  the  IPT  must  identify  all  of  the  government  and/or 
contractor  organizations  needed  to  support  the  achievement  of  the  PC/ALC  assigned  objectives.  The 
extent  to  which  contractors  will  be  involved  must  be  determined  as  part  of  the  strategy,  as  well  as  how 
they  will  be  procured  and  reimbursed  for  their  efforts  (see  D34).  Any  other  projects  or  programs  with 
which  the  PC/ALC  Phase  0  activities  might  interface  (Phase  0  munitions  proje^s  might  interface  with 
various  platform  programs  for  instance)  need  to  be  identified.  If  any  steering  or  working  groups  will  be 
formed,  they  should  be  identified,  their  general  role(s)  and  responsibilities  should  be  documented,  and  an 
OPR  assigned  to  ensure  their  timely  formation  (see  D22  and  D23).  When  all  of  the  participants  have 
been  identified,  the  IPT  must  determine  how  they  will  be  organized  to  accomplish  the  work  required  to 
achieve  their  assigned  Phase  0  objectives.  Organizational  responsibilities  should  be  assigned  and 
agreed  to  through  a  Memorandum  of  Agreement  (MOA)  or  other  commitment  document,  if  appropriate. 

Once  the  strategy  and  organization  have  been  determined,  the  IPT  should  identify  all  of  the 
tasks  necessary  to  complete  each  of  PCs/ALCs  assigned  objectives  and  detennine  who  will  lead  the  task 
and  the  amount  of  time  and  resources  required  to  complete  each  task.  Doni  just  focus  on  technical 
activities.  You  also  need  to  account  for  tasks  aixf  time  required  tor  administrative  and  management 
activities.  A  good  example  here  would  be  accounting  for  tasks  and  time  to  manage  and  reduce  or 
eliminate  identified  project  risks  (see  AFMCP  800-52  tor  more  information  on  risk  management).  Both 
government  and  contractor  tasks  should  be  included  in  this  assessment.  Well-defined  entrance  and  exit 
criteria  should  be  established  tor  each  task  identified.  Identifying  this  information  is  critical  to  developing 
an  event-driven  schedule  that  is  based  upon  the  successful  completion  of  identified  tasks  and  objectives. 
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Also  with  this  information,  the  IPT  can  ^stify  schedule,  ftjnding,  manpower.  arKf  other  needs  required  to 
achieve  their  assigned  objectives.  If  the  IPT  receives  top-down  direction  to  complete  tasks  by  a  given 
date,  this  information  will  typically  allow  the  IPT  to  more  successfully  negotiate  a  more  reasonable 
timeline.  Failure  to  develop  this  information  typicaNy  results  in  high-risk  calendar-driven  schedules  that 
have  an  undetermined  chance  of  successful  completion. 

Phase  0  planning  and  cooreUnation  can  be  very  frustrating  and  time  consuming.  At  this  very 
early  juncture  in  an  emerging  acquisition  program,  all  of  the  ot^ectives  of  Phase  0  may  not  be  clear,  or 
even  well  defined,  making  planning  very  difficult.  Phase  0  plans  are  often  developed  only  at  a  very  high 
level,  (i.e.  strategy  only),  with  initial  corresponding  schedules,  resource  needs,  and  commitments 
"guesstimated*  by  the  project  team.  This  is  OK.  if  as  the  objectives  of  the  activity  become  clearer  with 
time,  the  details  of  the  plan  are  filled  in  incrementally  as  the  team  proceeds  towards  each  objective  to 
account  for  this  better  understanding.  As  the  details  are  filled  in,  the  IPT  must  exercise  appropriate 
judgement  to  adjust  schedules  and  resource  needs  as  required.  Such  an  approach  can  allow  the  IPT  to 
more  rapidly  develop  arKf  coordinate  their  plans  and  can  he^  maintain  momentum  and  minimize  the 
amount  of  rework  required  if  the  strategy  changes.  There  are  drawbacks  to  this  incremental  approach, 
however.  The  initial  "guesstimates*  are  usually  fraught  with  errors  because,  in  haste,  the  IPT  didnl  think 
through  all  of  the  processes  required  to  complete  each  task.  More  likely,  however,  once  the  IPT  starts  to 
execute  these  "high  lever  plans,  they  won1  be  able  to  firxf  time  to  follow  up  on  the  details  they  omitted 
earlier.  This  typically  results  in  sche^le  slips,  increases  in  funding  and  manpower  requirements,  and 
lower  quality  products  than  desired  because  mandatory  reviews  or  approvals  were  overlooked, 
necessary  tasks  were  forgotten,  other  task  results  wereni  available  in  time,  or  a  host  of  other  reasons. 
What  the  IPT  wants  to  avoid  is  the  attitude  that  "there's  not  enough  time  to  do  it  right  the  first  time,  but 
we'll  find  time  to  do  it  over  again  if  we  have  to."  Developing  and  coordinating  plans  in  as  much  detail 
and  as  early  as  possible  and  then  executing  and  measuring  progress  against  these  plans  is  the  best 
approach. 

After  the  plans  have  been  developed,  they  should  be  ctocumented  and  coordinated  within  the 
PC/ALC  and  with  any  supporting  organizations  (such  as  Industry)  before  being  forwarded  for  coordination 
and/or  approval  by  the  lead  MAJCOM.  The  "best  practices*  section  of  this  document  provides  an 
approach  to  documenting  the  Phase  0  plans.  This  documentation  can  also  serve  to  support  the  lead 
MAJCOM's  inputs  to  the  Program  Management  Directive  (PMD)  and  the  Acquisition  Decision 
Memorandum  (ADM),  if  it  chooses  to,  or  is  asked  to,  be  actively  involved  with  their  devebpment. 

8.  ENTRANCE  AND  EXIT  CRITERIA: 

a.  Entrance  Criteria 

MAJCOM  /CC  Direction  to  Proceed  to  Milestone  0  -  The  Operating  Command 
determines  they  have  identified  an  operational  need  that  they  do  not  believe  can  be  satisfied  by 
nonmateriel  means.  They  decide  a  MNS  must  be  written  and  request  an  Air  Force  decision  through 
USAF/XOR  to  proceed  to  a  Milestone  0  decision  (see  C12).  During  this  general  timeframe  the  User  and 
the  developer  should  get  together  and  begin  planning  for  Phase  0  activities. 

b.  Exit  Criteria 

Concept  Studies  Approval-  When  the  Milestone  Decision  Authority  (MDA)  is  satisfied 
with  the  MNS  and  any  requested  Phase  0  planning  information,  approval  is  given  to  proceed  with  Phase 
0  concept  studies.  The  MDA  will  issue  an  ADM,  and  AF/XOR  will  issue  a  PMD.  After  receiving  these 
documents  the  lead  MAJCOM,  in  partnership  with  the  acquisition  community,  should  update  Air  Force 
Phase  0  plans  as  required  to  bring  them  in  line  with  the  guidance  provided  by  the  ADM  and  PMD  (see 
C16,  D22.  and  D23). 
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9.  KEY  INPUTS  AND  OUTPUTS: 

a  Key  Inputs 

(1)  Phase  0  Purpose,  Objectives,  Cortstraints,  and  Assumptions  -  The  lead  MAJCOM 
should  explain  the  purpose  of  the  Phase  0  activities,  the  objectives  tor  PC/ALC  involvement,  and  any 
known  or  anticipated  constraints  and  assumptions  impacting  PC/ALC  Phase  0  activities.  The  PC/ALC 
should  work  closely  with  the  lead  MAJCOM  to  ensure  appropriate  objectives  are  assigned  and 
reasonable  constraints  arto  assumptions  are  applied  (see  C14).  This  information  forms  the  basis  of  the 
PC/ALC  planning  activities.  Any  plans  develop^  without  obtaining  a  coordinated  position  between  the 
lead  MAXOM  and  the  PC/ALC  regarding  this  information  will  not  likely  meet  the  objectives  of  Phase  0. 

(2)  Phase  0  Technical  Plans  -  The  technical  planning  information  developed  in  D20B  is 
a  sub-set  of  the  planning  being  accomplished  by  this  activity.  The  information  developed  from  that 
activity  should  be  treated  as  an  integral  part  of  this  activity. 

(3)  Phase  0  Contracted  Studies  Strategy  -  DoD  policy  requires  that  the  contracting 
approach  must  permit  an  equitable  and  sensible  allocation  of  risk  between  Government  and  Industry 
(see  0000  5000.1 ,  Part  1 ,  paragraph  3).  The  strategy  for  procuring  contracted  studies  is  developed  in 
034,  and  is  also  a  sub-set  of  the  plannirrg  being  ixxomplished  by  this  activity.  The  information 
developed  from  that  activity  should  also  be  treated  as  an  integral  part  of  this  activity. 

(4)  Pre-Milestone  0  Database  -  It  is  imperative  that  the  planning  and  technical 
information  generated  to  support  the  Milestone  0  decision  be  analyzed  for  its  impact  on  Phase  0. 

Analytic  baselines  such  as  groundnjles,  assumptions,  threat  descriptions,  scenarios,  force  stoicture, 
operational  and  support  corx:epts,  and  other  planning  numbeis  will  greatly  impact  future  analytic  results 
and  must  be  accounted  for  in  the  Phase  0  plans.  These  planning  inputs,  and  the  resutts  of  preliminary 
trade-off  studies  must  be  captured  and  transferred  to  the  Phase  0  effort  to  ensure  consistency  and 
continuity  and  to  avoid  duplication  of  effort  (see  015). 

b.  Key  Output  -  The  focus  of  this  activity  is  for  the  PC/ALC  to  determine  it’s  preliminary  Phase  0 
planning  position  in  support  of  the  lead  MAJCOM's  preliminary  Phase  0  planning  activities  (see  Cl 4). 

The  PC/ALC  planning  position  should  document  all  constraints  and  assumptions  which  ajTply  to  their 
assigned  Phase  0  tasks.  It  should  also  document  the  PC//U.C's  business  and  technical  strategies,  and 
corres|X>nding  commitments,  for  accomplishing  assigned  Phase  0  tasks.  The  "best  practices"  section  of 
this  document  provides  an  approach  to  documenting  the  Phase  0  plans.  Where  api^icabte,  this 
information  should  follow  the  IWSM  philosophy  and  principles  outlined  in  AFMCP  800-60. 

(1 )  Phase  0  Constraints  and  Assumptions  -  All  known  constraints  arto  assumptions  that 
apply  to  the  PC/ALC  Phase  0  plans  should  be  identified  to  the  lead  MAJCOM. 

(2)  Phase  0  Strategy  and  Organization 

(a)  Strategy  -  The  PC/ALC  must  determine  its  business  and  technical  strategies 
for  accomplishing  assigned  Phase  0  objectives.  The  IPT(s)  should  identify  as  many  executable 
strategies  as  required  to  provide  the  lead  MAJCOM  with  flexibility  in  determining  an  integrated  Air  Force 
Phase  0  strategy.  The  IPT(s)  will  likely  have  to  work  many  iterations  of  different  strategies  with  the  lead 
MAJCOM  to  determine  the  best  overall  PC/ALC  alternative  for  the  Air  Force. 

(b)  Organization  -  The  IPT(s)  should  identify  ail  required  project  participants  and 
how  they  will  be  organized  to  accomplish  the  work  required  to  achieve  their  assigned  Phase  0  objectives. 
Organizational  responsibilities  should  be  assigned  and  agreed  to  through  a  Memorandum  of  Agreement 
(MOA)  or  other  commitment  document,  as  appropriate.  If  any  steering  or  working  groups  will  be  formed. 
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they  should  be  identified,  their  general  role(s)  and  responsibilities  should  be  documented,  and  an  OPR 
assigned  to  ensure  their  timely  formation  (see  022  arxf  023). 

(3)  Phase  0  Work  Sfafemenf  -  Given  a  business  and  technical  strategy,  the  PC/ALC 
should  iderMify  to  the  lead  MAJCOM  all  work  required  to  successfully  meet  assigned  Phase  0  objectives. 
Each  assigned  objective  should  be  broken  down  by  functional  discipline  to  identify  objectives  for  each 
discipline.  The  IPT(s)  should  identify  all  tasks  required  to  achieve  each  functional  objective  and  all  of  the 
interrelationships  with  other  functional  tasks.  Project  milestones  should  be  established  that  identify  the 
completion  of  major  groups  of  tasks  and/or  objectives.  Appropriate  entrance  and/or  exit  criteria  should 
be  established  jointly  by  the  lead  MAJCOM  and  the  IPT(s).  These  criteria  should  describe  what  event(s) 
must  occur  before  each  task  or  milestone  described  by  the  Work  Statement  can  be  considered  corr^ete 
A  description  of  the  identified  work  should  be  documented  in  some  form  of  Work  Statement  and 
coordinated  with  the  lead  MAJCOM. 

(4)  Schedule  Estimates  -  The  PC/ALC  should  provide  the  lead  MAJCOM  with  estimates 
of  the  time  required  to  achieve  the  exit  criteria  for  each  of  the  tasks  and  milestones  described  by  the 
Work  Statement.  Using  network  analysis  methods,  the  IPT(s)  should  analyze  the  Work  Statement  tasks 
and  milestones  and  corresponding  duration  estimates  to  develop  the  schedule  estimate.  The 
development  of  the  schedule  may  depend  on  known  resource  constraints.  See  the  'Irryylementation 
ToolsT  section  of  this  document  for  more  information  on  network  analysis. 

(5)  Resource  Estimates  -  Based  on  the  Work  Statement  identified  tasks  and  the 
corresporxJing  schedule  estimate,  the  PC/ALC  should  provide  the  lead  MAJCOM  with  estimates  of 
manpower,  funding,  and  other  resources  required  to  accomplish  assigned  objectives. 

(6)  ADM  and  PMD  Inputs  •  It  is  in  the  best  interest  of  the  Air  Force  for  the  lead 
MAJCOM  to  submit  recommendations  to  AF/XOR  regarding  the  content  of  the  Phase  0  ADM  and  the 

•  PMD.  The  key  outputs  listed  above  will  provide  all  of  the  PC/ALC  recommendations  required  for  the 

lead  MAJCOM,  in  coordination  with  the  acquisition  community,  to  develop  their  ADM  and  PMD  position. 

10.  KEY  REFERENCES: 

-  DoD  Directive  5000.1 , 23  Feb  91 ,  'Defense  Acquisition,*  provides  overall  DoD  defense  acquisition 
policies. 

•  DoD  Instruction  5000.2,  23  Feb  91 ,  "Defense  Acquisition  Management  Policies  and  Procedures," 
Section  E,  paragraph  2,  provides  DoD  policies  on  program  plans. 

-  AFMC  Pamphlet  800-60,  31  Mar  93,  "Integrated  Weapon  System  Management  (IWSM)  Guide," 
describes  AFMCs  IWSM  philosophy  and  provides  guidance  and  evolving  processes  for  implementing 
this  philosophy. 

■  AFMC  Guide  on  Integrated  Product  Development  (IPD).  25  May  93,  describes  AFMCs  IPD  phitost^hy 
and  provides  guidance  and  evolving  processes  for  implementing  this  philosophy. 

•  AFMC  Pamphlet  800-52,  4  Dec  92,  "Acquisition  Risk  Management  Guide  (Preliminary),"  identifies 
potential  risk  areas  and  tools  and  techniques  for  risk  management. 

•  AF  Policy  Letter  91M-001 , 20  Jun  91 ,  "Early  Industry  Involvement  in  Acquisition  Planning,"  establishes 
SAF  policies  regarding  early  Industry  involvement  in  acquisition  planning. 

•  AFMCR  500-13,  "Commanders  Policy  -  Systems  Representative  (SYSREP),"  describes  AFMCs 
policies  regarding  the  role  of  the  SYSREPs  and  the  acquisition  teams  interface  with  them. 


D-313 


NowM 


11.  PLANNING  GUIDANCE: 

a.  DURATION:  The  duration  of  the  Phase  0  planning  support  activities  will  vary  depending  on  a 
variety  of  factors  such  as  potential  program  size,  complexity,  avail^le  resources,  political  sensitivity, 
number  of  organizations  involved,  joint  service  and/or  international  involvement,  etc.  The  major  driver 
will  likely  be  the  number  of  organizations  involved  since  thorough  coordination  of  all  aspects  of  the  plan 
is  required  to  have  a  high  confidence  in  its  executability.  For  fairly  simple  Phase  0  efforts,  the  PC/ALC 
should  allow  for  a  minimum  of  about  one  month  to  build  and  coordinate  planning  information.  For 
potential  DAB  programs  adequate  planning  arfo  coordination  could  take  more  than  6  months. 

b.  CONSTRAINTS: 

(1)  The  PC/ALC  must  include  all  constraints  and  assumptions  identified  by  the  lead 
M/VJ/'OM  as  part  of  their  planning  activities. 

c.  RESOURCES:  IWSM  guidance  stresses  the  use  of  IPTs  to  accomplish  the  planning  for,  and 
subsequent  execution  of,  AFMC  supported  projects  or  programs  (see  AFMCP  800-60,  Chapter  2, 
paragraph  e.4).  Using  this  concept,  all  PC/ALC  functional  disciF>lines  (i.e.  XRs,  program  management, 
engineering,  logistics,  financial  management,  test,  contracting,  studies  artd  analysis,  labs,  industry,  etc.) 
should  be  actively  involved  as  a  team  to  develop  the  PC/ALC  planning  position.  The  assigned  IPT 
leader,  or  the  lead  PC/ALC  Commander,  may  want  to  convene  a  PC/ALC  or  AFMC  ASP  to  review  and 
approve  the  recommended  PC/ALC  position.  The  IPT  should  assign  at  least  one  full  time  resource  for 
development,  maintenance,  and  continuing  analysis  of  the  plans  and  schedule. 

d.  LESSONS  LEARNED:  The  following  lessons  learned  are  just  summarizations  of  a  few  of  the 
applicable  planning  lessons  extracted  from  the  OoD  Lessons  Learned  Database  (LLD).  Information  on 
how  to  access  the  LLD  can  be  found  in  the  "Implementation  Too/s"  section  of  this  document. 

(1 )  Personnel  Assigned  to  Joint  Service  Acquisition  Programs  •  Joint  Service  acquisition 
programs  have  sen/ice-unique  requirements  tiiat  need  to  be  addressed  in  order  to  avoid  fielding 
unsupportaWe  systems  (see  LLD  - 1408  (Air  Force)). 

(2)  Scheduling  of  Programs/Projects  -  When  one  milestone  in  a  program/project  slips, 
irreversible  problems  can  be  created  unless  the  impacted  milestones  are  also  slipped  or  other 
management  actions  taken.  Programs/projects  attempting  to  manage  without  knowing  the  critical  path 
will  most  likely  deliver  an  incomplete  product  late  and  over  budget  (see  LLD  - 142  (Air  Force)). 

(3)  DoD  Facility/National  Laboratory  Capabilities  -  Extensive  government  research, 
development,  test,  and  evaluation  (RDT&E)  capabilities  are  available  to  support  acquisition  programs. 
Potential  savings  to  the  government  have  been  lost  by  not  considering  in-house  resources  and 
capabilities  to  support  program/project  objectives  (see  LLD  - 1469  (Air  Force)). 

(4)  Project  Office  Functioning  as  an  Integrating  Contractor  -  Project  offices  must  develop 
a  manageiTient  approach  and  acquisition  strategy  that  are  consistent  and  complimentary  to  its  in-house 
capabilities  with  respect  to  personnel  and  analysis  tools  (see  LLD  - 1510  (Air  Force)). 

e.  BEST  PRACTICES: 

( 1 )  Develop  a  Master  Plan  and  Master  Schedule  -  The  planning  inputs  the  PC/ALC 
provides  to  the  lead  MAJCOM  should  be  documented  in  detail.  Once  the  PC/ALC  has  identified  and 
committed  to  provide  the  lead  MAJCOM  with  particular  Phase  0  products  and  senrices  on  a  given 
timeline,  it  is  necessary  for  the  IPT  to  know  at  any  point  in  time  where  they  stand  towards  meeting  those 
commitments.  Program  managers  have  recognized  for  years  that  baselining  to  a  master  schedule  of 
tasks  and  tracking  progress  and  change  against  that  baseline  is  the  best  way  to  attain  this  knowledge. 
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Good  business  practice  dictates  the  development  and  maintenance  of  a  master  program  schedule  that  is 
event  (not  caleridar)  driven  and  identifies  alt  of  the  tasks  and  their  interrelationships  required  to  achieve 
all  commitments. 


To  develop  a  Master  Schedule  requires  that  certain  planning  information  exist.  For  the  purpose 
of  this  discussion,  this  information  will  be  provided  by  the  Master  Plan.  The  Master  Plan  needs  to 
identify  all  the  tenns  of  any  agreements  between  the  PC/ALC  and  the  lead  MAJCOM  for  Phase  0.  It 
should  be  developed  by  the  IPT  and  should  integrate  all  of  the  functional  disciplines  business  arxf 
technical  plans  and  strategies  to  provide  a  single  view  of  the  project  direction.  It  should  identify  all 
participating  organizations,  their  roles  and  responsibilities,  and  how  they  will  organize  to  meet 
commitments.  AFMC  provides  no  set  format  or  guidance  for  such  a  planning  document,  however  an 
outline  of  the  content  might  be; 


-  Audience  List 
•  Work  Statement 
••  Purpose 
"  Objectives 
••  Constraints 
"  Assumptions 


-  Project  Environment 

-*  Organization 
--  Management  and  Control 
--  Other  Environmental  Factors 

-  Resource  Requirements 

-  Milestone  Schedules 


The  resource  requirements  and  milestone  schedules  are  surnmaiizations  from  the  Master 
Schedule,  and  are  documented  after  the  Master  Schedule  has  been  developed.  Thus,  the  Master  Plan 
provides  a  complete  summary  of  the  work  to  be  accomplished  by  the  PC/ALC,  what  resources  are 
required  to  accomplish  the  work,  their  responsibilities,  how  they're  to  be  organized,  and  the  overall 
schedule  required. 


The  Master  Schedule  identifies  all  the  activities  required  to  achieve  each  of  the  objectives 
identified  in  the  Master  Plan.  In  addition  the  Master  Schedule  depicts  the  order  in  which  the  activities 
must  be  performed,  provides  estimates  for  the  calendar  time  required  to  complete  each  activity,  and 
provides  start  and  end  dates  for  each  activity.  There  are  a  vanety  of  references  that  provide  detailed 
information  on  how  to  develop  and  track  schedules;  see  the  "IrTvIementation  Tools"  section  of  this 
document  for  more  information.  Like  the  Master  Plan,  AFMC  provides  no  set  format  or  guidance  for 
such  a  Master  Schedule  document,  however  an  outline  of  the  content  might  be; 

Rec^ired  Activities  (Work  Breakdown  Structure  Format) 

-  Purpose  and  Objective 

-  Entrance  and  Exit  Criteria 
■■  Inputs  and  Outputs 

Schedule  Data  (for  each  activity) 

--  Predecessor /Activities 
--  Duration 
■■  Constraints 
■■  Resource  Requirements 
Network  Analysis  of  Required  Activities 
Schedule  Chart  (Milestone  Gantt  Format  Preferred) 

The  responsibility  for  developing  a  Master  Plan  and  Schedule  belongs  to  the  IPT.  It  is  IPT 
leaders'  responsibility  to  ensure  all  supporting  organizations  participate  in  developing  a  logical  and 
cohesive  plan  that  can  be  realistically  executed  given  known  constraints,  (i.e.  schedule,  resources,  etc.). 
Failure  to  do  so  will  typically  lead  to  the  IPT  establishing  commitments  which  are  not  achievable.  Once 
the  Master  Plan  and  ^hedule  have  been  coordinated  by  all  participating  activities,  they  are  baselined. 
All  progress  is  tracked  and  compared  against  these  baselines.  All  changes  to  these  baselines  are 
evaluated  for  impacts  to  resource  and  schedule  requirements.  Major  changes  may  require  renegotiating 
commitments  arid  establishing  new  baselines.  Only  by  maintaining  the  Master  Plan  and  Schedule  in  this 
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way  will  the  IPT  have  the  insight  required  to  measure  progress  towards  meeting  their  assigned  objectives 
and  to  report  the  results  to  their  customer(s). 

Without  a  Master  Plan  and  Schedule,  the  IPT  wilt  be  forced  into  an  'on-the-fly'  or  *by  the  seat  ot 
the  pants*  approach  to  managing  and  executing  their  assigned  responsibilities.  The  IPT  will  only  have  a 
’gut  feel*  for  where  the  project  stands  toward  meeting  objectives.  Customer  requirements  will  likely  be 
overlooked,  or  not  fuHy  understood.  Required  tasks  will  te  forgotten,  or  worse  yet  not  even  recognized 
as  being  necessary.  Resource  requirements  will  be  difficult  to  justify  and  obtain.  Schedules  will  be,  at 
best,  unjustifiable  guesses  at  when  activities  will  be  complete,  or  driven  by  artificially  set  calendar  dates 
instead  of  achievement  of  milestones  or  events. 

(2)  Maintain  Model  Schedules  -  Maintain  historical  work  breakdown  structures  (WBS) 
and  schedules  for  activities  that  are  conducted  repeatedly  and  keep  them  on  file  for  future  reference  (see 
comment  under  Traps*).  Tailoring  historical  files  can  greatly  decrease  the  anxxjnt  of  time  required  to 
pull  together  future  plans  and  schedules.  There  are  many  Premilestone  0/1  activities  where  model 
schedules  exist  for  use  by  project  teams.  Contact  the  following  sources  for  more  information: 


■  ASC/FMCS,  Scheduling  Branch 

•  ASC/CYX  Source  Selection  Process 
'  ASC/YXD  Pre-Milestone  I  Process 

■  ASC/SDF  Schedule  Initiative 

•  ASC/YTX  Generic  Basket  SPO  Schedule 

■  ESC/FMA  Program  Scheduling  Initiative 
System 

•  ASC/ALLB  (CSNAS) 


DSN  785-6101 
DSN  785-761 3 
DSN  785-1847 
DSN  785-9777 
DSN  785-7177 
DSN  478-5376 

DSN  785-6587 


(3)  Build  an  Early  Partnership  with  Industry  -  It  is  Air  Force  policy  (see  AFP  91 M-001 )  to 
facilitate  early,  open,  and  effective  communications  between  industry  and  government  during  the 
acquisition  planning  process.  This  early  communication  is  vital  to  achieving  ultimate  program  success. 
Industry  participation  in  Pre-Milestone  I  activities  can  be  a  great  benefit  for  both  the  government  and  the 
industry  participants.  The  Government  can  readily  tap  years  of  industry  irvJependent  research  and 
development  (IR&D)  and  impact  future  industry  IR&D  spending  or  schooling  plans.  Industry  can  gain 
insight  to  early  Government  planning  information  to  develop  better  long  range  plans  and  put  themselves 
in  a  better  competitive  position  if  an  acquisition  program  actually  does  develop. 

(4)  Get  the  AFMC  Systems  Representative  (SYSREP)  Involved  -  The  SYSREP  provides 
a  day-to-day  interface  between  AFMC  and  (grating  commands  in  a  number  of  key  areas.  These  areas 
include  needs  formulation,  requirements  refinement,  technology  planning,  development  and  evaluation, 
and  systems  requirements  fomHJlation  and  evaluation.  It  is  AFMC  policy  (see  AFMCR  500-18)  for  the 
SYSREP  to  be  aware  of,  and  support,  all  AFMC  activities  with  the  Operating  Commands.  Let  the 
SYSREP  know  what  you're  doing. 

(5)  Consider  Government  Facilities  Capabilities  -  The  IPT  should  identify  and  evaluate 
DoD  laboratory  facilities  which  may  have  the  available  expertise  and  capabilities  to  perform  some  of  the 
required  development  and/or  testing  needed  to  meet  project  requirements.  Visits  to  these  facilities  would 
instill  confidence  in  the  team  as  to  the  abilities  of  these  personnel  and  their  facilities.  The  benefits  of 
using  these  in-house  resources  instead  of  contractors  could  be  significant  in  terms  of  cost  savings, 
without  giving  up  product  quality  or  negatively  impacting  schedule. 

(6)  Team  Training  tor  IPT  Pesonnel  -  One  of  the  most  critical  areas  of  program 
development  and  execution  is  the  formation  of  a  solid,  cohesive  team  early  in  the  acquisition  process. 
Once  the  initial  IPT  merrfoers  are  identified,  team  training  should  be  provided  to  the  entire  IPT  as  a 
group.  As  the  program  expands,  team  trainir^  should  be  provided  to  all  new  personnel,  regardless  of 
their  position  in  the  program.  Team  training  is  available  through  your  local  Total  Quality  (TO)  office. 
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f.  TRAPS: 

(1 )  Lack  of  Planning/Management  Focus  -  Ml  too  often  project  planning  is  completed 
and  agreement  is  sought  with  the  lead  MAJCOM  as  a  square-filling  exercise.  This  typically  leads  to  low 
quality  plans.  Because  of  this,  the  planning  documents  are  ignored  by  management  and  project 
partidpcmts.  The  value  of  documents  like  the  Memorandum  of  Agreement  (MOA),  Master  Plan,  and 
Master  Schedule  is  that  they  provide  management  and  project  participants  with  documented  and 
appropriately  coordinated  information  regarding  program  direction,  how  the  activities  wilt  be  orchestrated 
to  meet  that  direction,  and  the  baselined  schedule  agreed  to  for  implementing  the  plans.  Plarming  is 
necessary  to  provide  both  management  and  program  participants  with  information  critical  to  identifying 
and  successfully  executing  their  assigned  program  responsibilities. 

(2)  Use  of  Model  Schedjies  -  Just  as  model  schedules  can  help  reduce  workload,  they 
can  also  increase  the  risk  of  omission  of  critical  tasks  for  the  current  activity,  or  the  carryover  of  previous 
mistakes.  The  IPT  should  only  use  the  model  schedule  as  a  starting  point,  and  tailor  to  meet  their  needs. 
The  IPT  must  still  do  a  thorough  review  to  ensure  the  tasks  suggested  by  the  model  schedule  are 
complete,  meet  their  assigned  objectives,  and  doni  have  hidden  problems. 

12.  IMPLEMENTATION  TOOLS: 

a.  ASC/YX  Program  Development  Process  Products  •  ASC/YX  has  developed  several  tailorable 
products  that  will  help  acquisition  teams  develop  pre-milestone  I  plans  and  strategies.  For  copies  of  any 
of  the  following,  contact  ASC/YXDP,  DSN  785-1847. 

(1 )  Pre-Milestone  I  Process  Flow  Charts  -  These  flow  charts  provide  a  pictorial  view  of 
the  overall  acquisition  management  process  through  the  Milestone  I  decision.  Process  tasks  and 
interfaces  with  other  each  other  are  identified  as  well  as  who  has  the  responsibility  for  ensuring  task 
completion. 


(2)  Pre-Milestone  I  Process  Checklist  -  This  checklist  organizes  the  tasks  displayed  by 
the  process  flow  charts  into  a  taiforable  work  breakdown  structure  format  for  use  by  project  teams 
developing  Phase  0  plans.  The  checklist  supports  more  detailed  definition  of  tasks  than  is  provided  by 
the  process  flow. 

(3)  Program  Development  Process  Guide  -  This  process  guide  documents  the  Pre 
Milestone  I  program  development  process.  It  provides  narrative  descriptions  of  the  Pre  Milestone  I 
tasks.  These  descriptions  are  both  broad  based,  covering  an  overall  view  of  pre-milestone  I  acquisition, 
and  detailed,  covering  each  of  the  tasks  typically  required  to  be  accomplished  to  achieve  a  Milestone  I 
decision.  The  detailed  task  descriptions  provide  information  on  the  following  for  each  of  the  Pre 
Milestone  I  tasks  identified; 


Description  of  the  Activity 
Owner(s)  and  Stakeholder(s) 
Purpose  and  Objective(s) 
Requirement(s)  and  References 
Entrance  and  Exit  Criteria 
Key  Inputs  and  Outputs 
Available  Implementation  Tools 


-  Panning  Guidance 

••  Task  Duration 
••  Constraints 
Resources 
-•  Lessons  Learned 
Best  Practices 
-  Traps 


b.  Air  Force  Acquisition  Model  (AFAM)  -  The  AFAM  software  is  an  AFMC  managed,  PC-based, 
acquisition  management  tool  that  is  designed  to  provide  acquisition  managers  wkh  a  description  of  the 
basic  system  acquisition  process,  down  to  a  practical  level  of  definition.  Information  can  be  accessed 
related  to  task  d^riptions,  refererx:es,  lessons  learned,  oest  practices,  nominal  timelines,  etc.  The 
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descriptions  ot  the  acquisition  tasks  are  based  upon  a  functional  decomposkion  of  the  acquisition 
process  known  as  a  task  breakdown  structure  (TBS).  The  AFAM  software  is  avaHabte  at  no  charge  to 
requesting  Government  organizations.  For  more  information,  or  to  request  a  copy  of  the  software, 
contact  ASC/CYM,  DSN  785-0418. 

c.  Lessons  Learned  Database  •  Air  Force  acquisition  personrtel  can  gain  access  to  a  large 
dati^se  of  acquisition  lessons  learned  through  the  PC-based  'Automated  Lessons  Learned  Capture  and 
Retrieval  System  (ALLCARS)*  software.  The  database  this  software  draws  from  is  supported  by  the  Air 
Force,  the  Army,  the  Navy,  and  the  Marine  Corps.  For  more  information  contact  ASC/CYML,  DSN  785- 
3454. 


d.  Scheduling  Methodologies  and  Software 

(1 )  Either  of  the  followirrg  government  refererKes  will  provide  sufficient  insight  to 
network  analysis  and  other  common  scheduling  methodologies  that  have  gained  wide  acceptance  within 
the  government  arKf  business  communities: 

-  'Scheduling  Guide  for  Program  Managers,*  Defense  Systems  Management 

College  (DSMC),  Jan  90 

-  'Program  Control  Handbook  -  Volume  III  Schedulir  ESC/FMBP,  Nov  88 

(2)  There  are  many  inexpensive  computer  software  packages  available  for  developing 
and/or  trackir^  project  tasks  and  schedule.  Listed  below  are  some  of  the  packages  known  to  be  in  use 
at  ASC.  For  just  about  any  activity  that  occurs  Pre  Milestone  0  or  Pre  Milestone  I,  any  of  the  following 
should  suffice: 


4r, 


Product 

■  Microsoft  Project* 

•  CA  Super  Project 

•  Timeline 

-  Hanrard  Project  Manager 
CSNAS 

■  MacProject 

•  Open  Plan 


Platfbm(s) 

DOS,  Windows.  Mac 

DOS,  WirKlows 

DOS,  WirKlows 

DOS,  Windows 

DOS,  VAX 

Mac 

DBASE 


Company 

Microsoft  Corporation 
Computer  As^iates 
Symantec 
A^on-Tate 

ASC/ALLB  (FREE  S/W  and  Training) 
Claris 

Welcome  Software 


*  The  trend  at  ASC  seems  to  be  toward  standardization  on  Microsoft  Project. 


(3)  If  your  software  needs  cannot  be  met  by  any  of  the  above  products.  Patricia  Sedlak, 
ASC/SMPB,  and  Weridy  Fleisher,  ASC/YCPFB,  have  developed  a  methodology  (or  sel^ng  project 
management/scheduling  software.  This  methodology  is  documented  in  an  unpublished  report  entitled, 
"A  Project  Management  Scheduling  Software  Selection  Methodology,'  16  Sep  92.  Copies  of  this  report 
are  available  through  ASC/FMCS,  Scheduling  Branch,  DSN  785-6101. 
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1.  ELEMENT:  D20B.  TBS  1 .1 .1 .3  (IFC  93-3) 

2.  TITLE:  Draft  Technical  Plans  (AFMC  Centers) 

3.  ELEMENT  OWNER(S):  Project  Cadre;  Product  Center  Development  Planning  (XR  &  YX  @  ASC) 

4.  ELEMENT  STAKEHOLDER(S): 

a.  Implementing  and  Operating  Commands 

b.  Air  Staff  (USAF/XO  &  SAF/AQ) 

c.  Air  Force  Material  Command  (AFMC)  /XR  &  ST 

d.  Product  &  Logistic  Centers  (PC/ALCs) 

e.  Laboratories 

f.  Intelligence  Agencies 

g.  Industry 

5.  REQUIREMENT: 

a.  DODI  5000.2,  Defense  Acquisition  Management  (DAM)  Policies  &  Procedures,  Jan  91 : 

(1)  Part  4,  Requirements  Evolution  and  Affordability.  Sections  A  &  B,  and 

(2)  Part  1 1 ,  Program  Control  and  Review,  Sections  C.  D  &  E.  Review  plans,  procedures 

and  reports; 

b.  DOD  5000.2-M,  DAM  Documentation  &  Reports,  Feb  91,  Part  1  &  followii^.  Procedures  and 
formats  for  use  in  preparations  for  milestones,  reviews  and  other  key  decision  activities. 

c.  AF  Sup  1/DODI  5000.2,  DAM  Policies  &  Procedures,  Sep  92,  Parts  4  -  9,  Description  of  the 
system  acquisition  process  for  Air  Force  programs,  covering  cradle  to  grave  aspects. 

d.  AF1 10-601 ,  Mission  Needs  &  Operational  Requirements  Guidance  &  Procedures,  Feb  93, 
Instruction  for  developing  &  processing  AF  mission  needs  and  operational  requirements; 

e.  MIL-STD-499B,  Systems  Engineering,  Draft  May  92,  Section  3.8,  Systems  Engineering 
Process. 


6.  PURPOS&OBJECTiVE(S): 

a.  Purpose;  To  prepare  preliminary  technical  plans  for  Phase  0  in  support  of  the  Operating 
Command. 

b.  Objective(s);  To  ensure  the  System  Engineering  &  Configuration  Management  (SE/CM) 
philosophy  is  incorporated  into  the  process  and  to  conplete  the  following  tasks  in  support  of  the  PC/ALC 
Phase  0  (banning  activities: 


(1)  Identify,  by  functional  discipline,  preliminary  Phase  0  technical  tasks  (for  both 
government  and  potential  contractors)  and  their  interfaces; 

(a)  Traditional  Engineering  (such  as  electronics,  therrrxxfynamics, 

aerodynamic,  etc.). 

(b)  Specialty  Engineering  (such  as  Logistics,  Maintenance,  Human 

Factors,  etc;.). 


(c)  Test  Engineering. 


(e)  Studies  and  Analyses. 


(f)  Security. 


(2)  Initiate  or  update  technical  plans  development  for. 

(a)  Government-level  Systems  Engineering  Master  Plan  (SEMP)  outline. 

(b)  Program  Protection  Plan  (PPP). 

(c)  Logistics  Support  Analysis  (LSA)  Strategy. 


(3)  Identify  additional  specific  working  groups  to  initiate  developnnent  of. 

(a)  the  Baseline  Concept  Descriptions  (BCDs). 

(b)  strawman  System  Rec^irements  Document  (SRD). 

(c)  strawman  System  Engineering  Master  Schedule  (SEMS). 

7.  DESCRIPnON: 

These  preliminary  plans  for  the  anticipated  Phase  0  efforts  are  complementary  to  the  plans  being 
defined  fc>r  the  overall  programmatic  aspects  (D20A)  and  are  to  be  used  by  the  Operating  Corivnand  in 
completmg  their  overall  draft  Phase  0  plans  (C14).  The  scope  of  the  activity  at  this  stage  is  to  establish 
a  reasonably  accurate  technical  framework  for  the  tasks  and  other  activities  that  should  start  or  continue 
after  a  positive  MS  0  decision. 

It  is  anticip^ed  that  these  preliminary  plans  will  be  reviewed  for  updates  after  the  MS  0  approval, 
with  the  primary  objective  at  this  point  being  to  provide  a  complete  outlook  of  the  technical  needs  and 
activities  to  be  covered  during  a  Phase  0  effort.  Some  of  the  technical  activities  will  extend  or  build  upon 
the  preliminary  deveiopments  through  this  point  in  the  overall  effort  (D1 5.  D29,  D30).  Contracting 
strategies  ne^  to  be  identified  and  outlined  in  order  to  feed  the  Operating  Command's  overall  strategy 
developments  (D34).  An  important  aspect  of  this  strategy  is  the  identification  of  any  Government 
Furnished  Equipment  (GFE)  that  would  be  targeted  for  this  Phase  0  efforts.  Work  statement  drafts 
should  be  defined  that  cover  both  in-house  (government)  and  contracted  activities.  This  step  will 
streamline  the  efforts  to  update  plans  following  a  positive  MS  0  decision.  Other  functional  plans  should 
either  be  drafted  or  updated  in  preparation  for  the  Phase  0  effort.  A  key  development  for  the  technical 
area  is  defining  a  strawman  Systems  Engineering  Management  Plan  (SEMP).  This  will  become  the 
overall  guidance  for  the  project  team's  technical  activities.  The  SEMP  should  show  a  fully  integrated 
engineerir^  effort,  with  the  organization,  direction  and  check-points  for  the  Phase  0  activities. 
Coordination  among  the  stakeholders  is  very  important  to  ensure  consistent  perspectives, 
understandings,  and  commitments  for  the  goals,  objectives,  resources,  and  schedule. 

8.  EKTRANCE  AND  EXIT  CRITERIA; 

a.  Entrance:  Initiation  occurs  when  the  Operating  Command  has  achieved  a  validated  MNS  and 
has  decided  that  an  approval  will  be  sought  (MS  0)  to  pursue  the  development  of  a  more  detailed 
acquisition  position. 

b.  Exit:  The  activity  is  concluded  when  the  Operating  Command  determines  that  a  complete 
MS  0  decision  support  padutge  has  been  developed. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Key  Inputs: 

(1)  Support  to  the  Draft  Phase  0  planning  being  provided  to  the  Operating  Command 
(D20A)  ~  developed  in  close  coordination  between  the  programmatic  and  technical  aspects  of  a  Phase  0 
effort. 

(2)  Access  to  the  Project  Database  (D15)  for  technical  details  and  decision(s)  -  defining 
the  technical  areas  to  be  addressed  in  Phase  0  will  deperid  on  a  consistent  extension  from  details 
developed  in  earlier  activities.  The  database  is  a  key  repository  of  the  information  that  is  both  needed 
and  developed  by  analyses  and  simulations. 

(3)  Contract  strategy  interfaces. 

(4)  Laboratories  &  Industry  Interfaces  ~  these  two  information  and  resource  areas  are 
an  important  aspect  of  the  activities  dealing  with  identifying  and  developing  descriptions  of  potential 
system  concepts. 


NowtS 


b.  Key  Outputs; 

(1)  Draft  Work  Statements  -  (D20A  &  034)  --  the  PC/ALC  identifies  afl  (technicai) 
activities  that  will  be  required  to  successfully  accomplish  Phase  0  objectives.  These  cover  both 
government  and  industry  tasks,  along  with  the  timeframe  of  their  execution.  Coordination  with  the 
Operating  Command's  draft  plans  (  C14)  is  important. 

(2)  Draft  Functional  Plans  -  (023) 

(a)  Outline  for  the  SEMS  (Systems  Engineering  Master  Schedule). 

(b)  Strawman  SEMP  (Systems  Engineering  Managemem  Plan). 

(c)  Initial  ILSP  (Integrated  Logistics  Support  Plan)  -  outlines  proposed 
supportability  objectives  for  the  aMematives. 

(d)  Updated  LSA  (Logistics  Support  Analysis)  Strategy  -  identifies  tasks  and 
subtasks  to  be  performed. 

(e)  Outline  for  Test  &  Evaluation  Master  Plan  (TEMP). 

(f)  Strawman  PPP  (Program  Protection  Plan). 

(3)  Strawman  BCD  (Baseline  Concept  Description)  -  (D23). 

(4)  Identify  needed  technical  working  groups  -  (D23). 

10.  KEY  REFERENCES: 

In  addition  to  Item  5.  Requirements  - 

a.  AFPD  10*6,  Operational  Requirements,  Jan  93,  Policy  directive  for  implementing  the  mission 
needs  and  operational  requirements  developmerrts. 

b.  DSMC,  Systems  Engineering  Management  Guide,  Jan  91 ,  describes  systems  engineering 
coTKsepts  and  techniques. 

c.  MIL-STD-1388-1  A,  Logistic  Support  Analysis  (LSA),  Apr  83.  provides  general  requirements 
and  task  descriptions  for  performance  of  LSA. 

d.  MIL-l-INBK-499-3,  System  Engineering  /  Configuration  Management  (SE/CM)  -  Life  Cycle 
Application,  Draft  Aug  92. 

11.  IMPLEMENTATION  TOOLS: 

a.  ASC/YX  Program  Development  Process  Product;  these  include  a  process  flow  chart,  a 
process  checklist  and  a  process  guide  (see  D20),  Sep  93. 

b.  Air  Force  Acquisition  Model  (AFAM);  an  AFMC  managed  acquisition  tool. 

c.  MIL-HNBK  499-3;  process  guide. 

d.  Outline  from  AFR  800-3,  Acquisition  Management,  Engineering  for  Defense  Systems, 

17  Jun77 

e.  LSA  Users  Guide,  Mar  89. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  This  planning  preparation  activity  will  typically  take  1  -2  months  for  a  full 
system  deficiency  or  2  -  3  weeks  for  a  major  subsystem  or  component.  This  assumes  that  some 
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groundwork  has  been  laid  for  these  plans  during  the  execution  of  previous  activities.  Aspects  that  oouU 
lengthen  the  timeframe  include  number  of  organizations  involved,  particularty  across  PC/ALCs.  joint 
service  or  internatiorud  involvemenls.  and  political  sensMivities. 

b.  CONSTRAH4TS:  Priority  assigned  by  the  Operating  Command  for  the  planned  Phase  0  will 
directly  influence  the  level  of  effort  devoted  to  and  covered  by  the  preliminary  plans.  Also,  funckng  and 
support  constramts  wiH  affect  the  LSA/ILS  strategy. 

c.  RESOURCES;  Typically  1 0-1 2  persons  lor  a  kill  system  assessment  and  3-5  for  a  major 
subsystem  or  component.  This  activity  is  preferably  performed  by  an  integrated  product  team,  involving 
aH  principle  stakeholders  and/or  potential  participants  of  Phase  0. 

d.  LESSONS  LEARNED; 

(1)  The  technical  planning  activities  should  consider  the  synergy  from  cooper^ive 
government  and  industry  efforts  for  Phase  0.  Often,  the  government  resources  and  capabMiti^  can  be 
complemented  by  those  available  through  contracted  efforts.  This  adds  additional  emphasis  on 
maintaining  close  ties  to  industry  to  allow  effective  interfaces  at  key  points  in  the  overall  developments. 

(2)  The  technical  OPR  should  look  for  active  participation  from  all  team  members. 
Particular  attention  should  be  given  to  those  functiortal  areas  that  have  direct  connection  to  the  type  of 
need  being  addressed.  This  is  not  just  a  passive  exercise;  the  team  members  should  be  effectively 
'committing*  the  identified  resources  as  p^inent. 

(3)  CXirirtg  this  important  step  to  a  MS  0  decision,  it  is  crucial  that  the  planning  team 
maintain  continual  communications  with  the  Operating  Command.  The  approach  used  throughout  AFMC 
is  to  utilize  the  SYSREP  (AFMC  representative  physically  located  at  the  MAJCOM,  usually  with  the 
Plans  and  Programs  or  Requirements  offices,  i.e.  /XP  or  /DR)  as  a  means  of  keeping  the  information 
exchange  a  dynamic  process. 

e.  BEST  PRACTICES; 

0)  The  preferred  approach  to  achieving  a  'seamless*  transition  from  Pre-MS  0  to  Post- 
MS  0  (Phase  0)  is  through  a  core  IPT.  This  will  allow  for  a  more  consistent  perspective  being  mairkained 
and  will  ensure  minimal  loss  of  key  information  during  the  transition.  Accepting  the  fact  that  some 
turnover  will  always  occur,  documentation  becomes  very  important  (see  D15). 

(2)  Attention  should  be  given  to  keeping  the  most  important  (key)  functional  area 
representatives  as  members  of  the  IPT.  Corporate  memory  is  not  easily  recover^  or  reconstructed, 
even  with  documentation. 

(3)  It  is  important  to  periodically  review  the  original  factors  that  evolved  during  the 
development  of  the  MNS.  This  is  the  main  driver ...  the  search  for  alternative  solutions  to  a  mission 
deficiency  or  need. 

f.  TRAPS; 

(1)  It  is  difficult  to  identify  the  point  where  planning  is  complete.  Often,  there  is  a 
tendertcy  to  define  the  intial  plans  in  great  detail  and  leave  the  rest  'fuzzy.'  The  plans  should  carry  the 
process  all  the  way  to  and  through  the  MS  1  decision  point. 

(2)  External  influences  can  have  an  affect  on  the  plans  at  this  stage.  Preliminary  plans 
for  Phase  0  should  emphasize  maintaining  an  open  and  broad  perspective  for  evaluating  potential 
alternatives.  When  pre-conceived  notions  about  the  'right'  solution  are  allowed  to  errter  the  process, 
they  often  will  result  in  a  very  narrowly  scoped  effort;  one  that  quickly  focuses  on  the  'right*  solution. 
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(3)  With  the  lack  of  formal  reviews  arKf  approvals,  the  preliminary  plans  could  have 
inckided  dependencies  or  made  reference  to  resources  that  may  or  may  not  be  available  during  Phase  0 
execution.  The  project  leaderfs)  should  enforce  an  approach  that  obtams  preliminary  commkments  that 
resources  will  be  available  and  at  the  proper  time. 

(4)  Small  project  teams  with  limited  representation  are  often  faced  (knowingly  or  not) 
with  having  to  pursue  activities  that  are  totally  supported  through  contracted  efforts.  Too  often  tNs  is  the 
preferred  choice,  even  when  there  are  adequate  resources  available  to  effectively  organize  an  in-house 
team.  It  is  vitally  important  that  the  IPT  exercise  this  planning  function  fuHy  and  seriously  address  the 
concept  of  an  in-house  team  paralleling  the  efforts  performed  by  industry. 

(5)  Developing  the  ILS/LSA  strategy  without  a  valid  support  concept  from  the  Operating 
Command  will  limit  identification  of  support  factors  and  tasks. 
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6.  PURPOSE  and  OBJECTIVES: 

a.  PURPOSE;  The  AFMC  Mission  Assignment  Process  was  established  to  ensure  all  the 
taskings  which  come  into  the  command  are  accomplished  by  the  most  capable  and  qualified 
organization. 

b.  OBJECTIVES;  The  overall  objective  of  establishing  and  institutionalizing  the  AFMC  Mission 
Assignment  process  is  to  ensure  we  do  our  best  to  satisfy  our  custoniers  by  providing  quality  service, 
quality  products,  timely  response  to  customer  needs  and  best  value  to  the  customer  and  the  command 

using  our  most  qualified  and  appropriate  resources.  These  objectives  are  driving  forces  the 
command  wants  to  capture  through  the  application  of  the  Mission  Assignment  Factors. 

7.  DESCRIPTION:  The  AFMC  Mission  Assignment  Process  is  the  first  major  action  taken  by  HQ  AFMC 
followir^  the  release  of  the  Program  Management  Directive  (PMD)  by  Air  Staff  (B1 0).  The  PMD  gets  tfie 
ball  rolling  by  including  the  phrase  ’AFMC  shall...”.  With  such  a  tasking  in  hand.  AFMC/XP  then  makes 
mission  assignments  to  the  appropriate  center  based  on  a  set  of  objectively  measurable  criteria  including 
areas  concerning; 

a.  customer  requirements, 

b.  technical  characteristics  of  the  proposed  assignment. 

c.  the  present  and  future  posture  of  the  command. 

d.  the  overall  needs  of  the  Air  Force  and  DoD. 
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It  is  important  to  remember  that  this  is  an  AFMC  process,  it  does  not  apply  to  assignments  of  or  to 
single  program  managers  (these  are  handled  through  the  PEO^OAC  chain  ol  command),  or  to  mission 
assignments  within  a  particular  laboratory  or  center  which  are  handed  by  the  respective  commander.  At 
ASC.  the  ASC/CC  makes  the  work  assignments  within  the  center  through  the  Review  New  Work  Process 
(078). 

The  Mission  Assignment  Process  is  applicable  to: 

a.  initial  assignments,  realignments,  and  rescissions  of  AFMC  management  responsibilities  for; 

weapon  systems 

support  sj^ems 

technology  groupings 

Federal  Supply  Classification  (FSC)  items 

special  programs 

and  special  projects 

b.  and  initial  source  of  repair  (SOR)  for  major  systems  and  engines. 

The  assignments  made  at  this  level  deal  primarily  wKh  the  manner  in  which  the  AFMC  infrastructure 
provides  resources  and  capabilities  to  the  single  managers  and  other  external  customers  and  allows  their 
management  processes  to  operate. 

In  order  to  ensure  efficiency  and  responsiveness  in  the  mission  assignment  process,  AFMC  has  divided 
the  various  types  of  taskings  or  work  which  come  into  the  command  into  three  categories. 

Category  I  assignments  are  those  taskings  which  are  non-Program  Management  Directive 
(PMD)  generated.  They  originate  with  the  customer,  who  takes  the  task  directly  to  the  center 
that  the  customer  feels  is  the  best  qualified  to  do  the  work.  Basically,  Category  I  taskings  by¬ 
pass  the  entire  AFMC  mission  assignment  process. 

A  hypothetical  example  may  help.  Let's  assume  Air  Combat  Command  (ACC)  has  walked 
through  their  mission  area  assessment  (MAA)  (IFC  BIk  #C1 )  and  preliminary  mission  need 
analysis  (MNA)(IFC  BIk  #C3)  using  the  strategy-to-task  technique.  They  discover  there  may  be 
a  shortfall  in  their  ability  to  destroy  relocatable  targets  such  as  SCUDs.  Armed  with  this 
information,  ACC  comes  to  ASC/XR  requesting  them  to  do  further  analysis  on  this  potential 
shortfall  and  to  discover,  if  possible,  what  areas  pertaining  to  SCUD  Killing  are  deficient,  (i.e. 
Mission  Need  Analysis).  ASC/XR  runs  an  entire  battery  of  analytical  excursions  using  a  variety 
of  models.  They  assess  the  tactics  employed,  the  airframes  tasked  with  this  mission,  types  and 
numbers  of  weapons  used,  availability  of  intelligence,  etc. 

At  the  same  time  all  this  is  going  on  between  ACC  and  ASC,  Space  Command  discovers  the 
same  shortfall  in  their  own  MAA.  In  Space  Command's  shortfall,  they  think  their  deficiency  lies 
in  their  inability  to  direct  a  laser  energy  weapon  against  a  detected  SCUD  launch  point.  Space 
Command  engages  the  services  of  SMC/XR  to  accomplish  the  MNA  activities  and  provide  the 
detailed  analysis  which  show  what  specific  areas  in  the  Space  Command’s  SCUD  Killing  mission 
are  deficient.  SMC/XR's  initial  analysis  hints  that  the  most  efficient  way  to  kill  SCUDs  might  not 
necessarily  be  from  a  satellite  platform.  In  order  to  explore  this  possibility  SMC  employs  the 
services  of  ESC/XR.  ESC  will  do  preliminary  analysis  on  the  possibility  of  improving  the 
Communication  links  with  more  earthbound  strikers  such  as  tanks,  surface-to-surface  missiles, 
orbiting  aircraft  etc. 

In  this  hypothetical  exam(Ae,  three  significant  taskings  were  created,  assigned,  and 
accomplished  totally  outside  the  AFMC  Mission  Assignment  Process.  This  is  the  norm  in  Pre- 
Milestone  0  activities.  AFMC/XP  has  no  wish  to  interfere  with  this  practice,  without  a  PMD  or 
some  other  kind  of  higher  headquarters  tasking  document:  the  AFMC  Mission  Assignment 
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Process  is  rx}t  a  player.  Other  types  of  taskings  which  would  fall  into  Category  I  would  be  things 
like:  Military  Irtterdepartmental  Purchase  Requests  (MIPRs),  another  service  request  for  work 
which  is  provided  directly  to  specific  Teat  Center  with  previously  assigned  responsibility  for  that 
type  of  test  activity,  etc. 

Category  tl  assignments  are  generally  those  taskings  resulting  from  PMD  revisions  in  which 
similar,  related,  or  follow-on  work  is  directed  to  a  single  manager.  Category  II  tasks,  like  the 
Category  I  tasks,  already  have  the  management  infrastmcture  in  F>lace.  The  difference  here  is 
that  Category  II  tasks  operate  under  a  dual  management  infrastmcture.  The  single  manager's 
infrastructure  operates  within  the  acquisition  chain  of  command  and  in  conjunction  with  the 
AFMC  infrastructure.  AFMC  is  to  provide  the  single  manager  (along  with  other  internal  and 
external  customers)  with  the  resources  and  capabilities  which  might  currerr.ly  be  lacking  in  the 
single  manager's  operation.  If  the  single  manager  already  has  all  the  assets  he  needs  to 
complete  this  new  tasking,  then  AFMC  is  out  of  the  picture. 

Again  a  hypothetical  example  might  make  this  a  little  easier  to  understand.  Assume  that  Wright 
Laboratory  discovers  an  electronic  device  which  when  installed  in  the  avionics  suite  of  a  B-1 B 
renders  the  entire  air  vehicle  as  stealthy  as  a  B-2.  The  concept  is  reviewed  by  ACC;  they  like  it 
and  they  want  it  installed  on  their  entire  B-1  B  fleet.  "Rie  B-IB  Program  Element  Monitor 
manages  to  get  the  B-IB  PMD  amended  to  include  the  integration  of  the  new  miracle  ‘cloaking 
device.’  Along  with  the  amended  PMD  comes  $100M  to  install  and  integrate  the  devices  into  the 
B-IB  avionics  suite.  The  devices  themselves  will  be  produced  by  the  lab  and  provided  as  GFE. 
The  Single  Manager  for  the  B-IB  would  receive  this  update  to  the  PMD.  In  order  to  assess  his 
ability  to  accomplish  this  task,  he  might  form  an  Integrated  Product  Team  (IPT)  to  research  the 
task  and  the  resources  required  to  complete  it.  The  IPT  completes  their  effort  and  determines 
that  they  will  need  some  assistance  from  ASC/EN  for  more  avionics  engineers,  as  well  as  a 
whole  host  of  folks  from  the  other  functional  home  offices  as  well.  This  would  be  a  tasking 
internal  to  ASC's  structure  (Category  I  type)  and  would  still  not  require  AFMC's  involvement. 

The  IPT,  however,  had  no  idea  as  to  who  would  be  the  best  Center  for  performing  the  depot 
level  maintenance  on  the  ‘cloaking  devices’-  now  the  AFMC  Mission  Assignment  kicks  in.  (If 
the  IPT  had  determined  that  Oklahoma  City  ALC  would  do  the  depot  work  on  the  boxes  and  the 
single  manager  would  have  tasked  them  to  do  so,  AFMC  might  still  have  become  involved  if 
Oklahoma  City  would  have  told  the  single  manager  they  were  unable  to  accomplish  the  new 
tasking  and  referred  the  work  back.  In  this  case,  the  single  manager  should  contact  the 
appropriate  HQ  AFMC  functional  organization.)  At  this  point  AFMC  has  an  several  of  options  to 
pursue  including  making  a  new  mission  assignment  through  the  Category  III  assignment  process. 

Category  III  assignments  are  the  New  Mission  assignments  and  generally  arrive  on  AFMC's 
doorstep  via  a  new  PMD.  Other  less  common  sources  of  new  mission  taskings  include  the 
Operational  Requirements  Document  (ORD),  other  formal  requests,  or  as  a  result  of  Internal 
management  processes.  New  assignments  include  activities  for  a  new  program,  technology, 
federal  stock  class  and/or  any  other  new  form  of  workload  tasked  to  AFMC  for  development, 
testing,  program  management,  and/or  support.  Major  mission  reassignments  and  those  taskings 
spilling  from  the  Category  11  example  above  are  also  included  in  this  category.  Category  III 
assignments  are  those  which  normally  come  to  mind  when  you  think  about  the  Mission 
Assignment  process. 

-  EXAMPLES;  A  couple  of  last  examples  should  bring  home  the  differences  in  the  three 
categories.  Rrst,  the  easy  one,  ACC  in  conjunction  with  ASC/XR  has  completed  the 
MNA  for  shortfall  in  the  muttirole  fighter  force.  The  initial  analysis  showed  a  serious 
deficiency  starting  in  the  year  2010.  ACC  drafts  and  staffs  a  Mission  Needs  Statement 
(MNS)  to  explore  various  concepts  which  could  solve  this  deficiency.  The  MNS  works  it 
way  to  the  Joint  Requirements  Oversight  Council  (JROC)  where  the  need  is  validated. 
The  JROC  attaches  their  assessment  of  the  need  and  forwards  the  package  to  the 
Defense  Acquisition  Board  (DAB)  for  the  Milestone  0  review.  A  favorable  review  results 
in  an  Acquisition  Decision  Memorandum  (ADM)  which  is  converted  into  a  PMD  by  the  Air 
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The  second  example  is  not  neatly  as  cut-and-dried  as  the  first.  Let's  assume  the 
multirole  forces  CE&D  activities  from  the  previous  example  result  in  a  new  aircraft  program,  the 
F-XX.  The  PMD  from  that  Milestone  II  decision  directs  AFMC  to  provide  Logistical  and  Depot 
Level  Support  for  the  future  F-XX.  IN  this  case,  the  Center  to  receive  this  tasking  is  not  nearly  as 
clear-cut.  Should  it  be  Sacramento  because  they  have  the  most  experience  working  with 
composite  type  airframes  or  should  it  be  Oklahoma  City?  Why  not  Hill,  since  they  have  the  most 
experience  with  previous  multirole  aircraft?  What  if  Robbins  has  the  most  facilities  and 
manpower  available  to  handle  such  a  large  task? 

An  even  better  example  would  be  a  derivative  of  the  National  AeroSpace  Plane 
(NASP)?  It  is  part  airplane  (ASC's  home  turf)  and  part  space  system  (SMC's  kingdom).  To 
resolve  this  issue,  AFMC/XP  runs  through  the  flow  . 

The  details  for  each  of  the  21  boxes  (Figure  D-21 .2)  .as  well  as,  the  activity  flows  for  the 
Labs,  FSC,  and  Test  mission  assignment  sub-process  flows  can  be  found  in  the  10  Feb  93  draft 
of  the  Mission  Planning  lnstmctk.n  forthe  AFMC  Mission  Assignment  Process 

Once  the  PMD  (or  other  tasking  element)  is  received,  an  action  officer  is  assigned  to 
determine  project  validity  as  a  Category  III  tasking.  In  our  example  it  is,  so  the  action  officer 
runs  the  diamond  gauntlet  and  determines  the  task  should  go  to  one  of  the  logistic  centers,  so  he 
enters  the  task  into  the  logistic  center  mission  assignment  sub  process.  The  Center  CCs  and 
single  managers  review  the  task  and  assign  a  series  of  multiplying  weights  to  be  applied  against 
each  of  the  standard  measurement  factors.  For  example,  if  the  task  were  to  select  the  logistics 
support  for  a  B-3  bomber,  then  facilities  might  be  a  highly  weighted  item  or  in  our  example  if  the 
F-XX  were  a  "thermoplastic*  jet  then  technical  experience  with  composite  materials  would  be  a 
big  player.  The  individual  centers  are  objectively  measured  against  each  of  the  factors. 
AFMC/XPX  will  then  assemble  the  results  and  put  together  a  Recommended  Assignment 
Package  for  review  and  approval  by  the  Program  Management  Mission  Element  Board 
(PMMEB).  The  winner  is  then  notified  of  the  results.  If  all  goes  according  to  the  book,  the  most 
capable  l^istics  center  should  now  be  in  charge  of  all  F-XX  support  operations. 

8.  ENTRANCBEXIT  CRITERIA: 

a.  Entrance  into  this  process  occurs  with  the  receipt  of  the  Milestone  0  PMD  from  HQ  AF/XOR 
(IFC  block  #B10). 

b.  Exit  criteria  have  been  met  when  AFMC/XP  assigns  the  new  mission  task  to  one  of  the 
command's  centers  of  excellence  for  execution.  In  the  case  of  ASC,  the  task  will  enter  into  the  ASC  New 
Work  Review  process  for  internal  allocation  (IFC  block  #D78). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Key  Input  is  the  tasking  document  which  is  normally  the  PMD  (IFC  block  #B10).  Taskings 
may  also  come  from  ORDs  (although  this  is  not  common  because  it  is  a  result  of  a  totally  unforseen 
requirement  that  sneaks  it  into  the  ORD),  verbal  requests,  or  some  AFMC  internal  realignment  activity 
and  the  resulting  documentation. 

b.  The  key  output  is  the  New  Mission  Assignment  Notification  Letter  (Letter  of  Assignment)  to  the 
center  awarded  the  new  mission  and  possibly  a  notification  package  to  Congress  explaining  the  rationale 
for  the  decision. 

10.  KEY  REFERENCES: 

a.  Draft  Policy  Directive  entitled:  AFMCCPD  XX-XX.  AFMC  Mission  Assignment  Process  and 
the  accompanying  draft. 
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b.  Planning  Instruction  ftw  the  Mission  Assignment  Process.  (Both  of  these  documents 

are  in  their  early  stages  of  evolution,  the  draft  is  dated  10  Feb  93  and  does  not  yet  have  a  Policy 
Directive  numerical  identifier.) 

1 1 .  IMPLEMENTATION  TOOLS:  Each  of  the  center  sub  process  activtty  flows  are  included  in  the 
above  reference  documents  along  with  a  very  brief  description  of  each  of  the  activity  blocks.  At  the 
present  time,  this  is  the  extent  of  the  mission  assignment  tool  set.  A  mission  Assignment  Process  Action 
Team  (MAPAT)  has  been  working  this  topic  since  Oct  92  and  is  expected  to  complete  its  activities  early 
summer  93.  The  team's  findings  are  to  be  presented  at  the  93  Summer  Horizon  Conference. 

12.  PLANNING  GUK)ANCE: 

a.  DURA'  ON:  Regardless  of  acquisition  category,  the  mission  assignment  process  must  be 
completed  in  no  n  ^re  than  28  days.  This  is  the  time  required  by  Air  Staff  to  respond  to  the  PMD. 
Strategic  planers  would  be  wise  to  allow  for  the  full  28  days  for  tasks  where  center  competition  is  likely 
(as  in  our  second  Category  III  example).  For  tasks  that  are  relatively  clear  cut,  plan  for  half  that  time. 

b.  CONSTRAINTS:  The  constraints  to  being  awarded  new  work  tasks  are  basically  the 
organization's  ability  to  fully  satisfy  the  factors  being  considered  for  the  task.  The  factors  are  generally 
the  same  for  all  tasks,  but  the  weighted  multipliers  change  given  the  unique  characteristics  of  the  task 
being  considered.  Again,  see  the  1 0  Feb  93  draft  of  the  Mission  Plannirio  Instmction  for  the  AFMC 
Mission  Assignment  Process  for  a  complete  listing  of  these  factors. 

c.  RESOURCES:  Basically  the  only  resources  required  to  accomplish  the  Mission  Assignment 
Process  are  the  total  availability  of  one  AFMC/XPX  action  officer  for  30  days  and  the  availability  of  all 
the  center  CCs  (or  designated  representatives)  for  a  1-day  Program  Management  Mission  Element 
Board  (PMMEB).  In  order  for  a  center  to  win  a  new  work  assignment,  resource  availability  will  be  a  key 
factor. 


d.  LESSONS  LEARNED:  None  identified. 

e.  BEST  PRACTICES:  Given  the  relatively  quick  turn-around  time  (by  acquisition  time  scales), 
it  is  a  good  idea  for  irKlividual  organizations  to  have  a  ready  assessment  of  their  excess  capabilities.  If 
your  center  wants  to  compete  for  a  piece  of  new  work,  they  will  likely  pulse  each  of  their  individual 
organizations  to  determine  their  net  capability  to  handle  the  new  task. 

f.  TRAPS:  In  regards  to  the  above  best  practice,  do  not  over  estimate.  Should  you  be  awarded 
a  new  work  assignment  based  on  an  over  inflated  estimate  of  your  capability,  the  result  could  be  much 
worse  than  not  getting  the  assignment  at  all.  It  has  happened  before  and  wilt  likely  happen  again.  Doni 
bite  off  more  than  you  can  chew.  A  failure  to  perform  a  task  due  to  over  estimate  in  capability  could 
jeopardize  the  center's  credibility  in  future  new  work  assignments  (past  performance  is  one  of  the 
measurement  factors). 


4 


•  { 


D-331 


1. 


1 


A 


I 


Nwn  > 

% 

« 

I 

THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


» 


« 


> 


» 


» 


D-332 


1.  ELEyENT:  D22.  TBS  1 .1 .4.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Update  Phase  0  Plans  (AFMC  Centers) 


NowM 


3.  ELEMENT  OWNER(S):  Assigned  AFMC  Product  Center  (PC)  and/or  Air  Logistics  Center  (ALC) 
Integrated  Product  Team  (IPT).  Typically.  Phase  0  systems  acquisition  activities  will  be  assig^  to  a 
PC,  with  very  limited  ALC  support  through  Milestone  I.  ALC  assignments  wiU  be  nrK)re  pervasive  with 
development  activities  associated  with  modifications  to  fielded  systems. 

4.  ELEMENT  STAKEHOLDER(S): 

Air  Staff  (USAF/XOR/TEP/INX.  SAF/AQX/FMC) 

-  Operating  Commands 

-  Air  Force  Materiel  Command  (AFMC/CC,  XR) 

■  AFMC  Product  and  Air  Logistics  Centers  (PCs/ALCs) 

5.  REQUIREMENT: 

-  AF  Regulation  800-1 , 16  Feb  90,  ‘Air  Force  Acquisition  System,*  paragraph  S.c,  identifies  the 
acquisition  management  responsibilities  of  Air  Force  acquisition  managers. 

-  AF  Instruction  10-601 . 1  Oct  92,  "Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,"  Attachment  2,  identifies  the  Major  Commarid  (MAJCOM)  and  Field  Operating  Agency 
(FOA)  pre-Milestone  I  responsibilities. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  To  complete  Phase  0  planning  and  organize  to  execute  the  Milestone  Decision 
Authority  (MDA)  Phase  0  direction  as  provided  through  the  Program  Management  Directive  (PMD)  and 
the  lead  MAJCOM  as  assigned  by  the  PMD. 

b.  Objective(s): 

(1 )  Phase  0  Plans  Approval  -  After  updating  the  Phase  0  plans  to  account  for  PMD 
direction,  the  IPT  should  obtain  appropriate  approval(s)  before  executing  the  plans.  The  appropriate 
level(s)  of  approval  will  depend  on  the  significance  of  the  activity  and  should  be  identified  by  the  lead 
MAJCOM. 

(2)  Establish  Required/Desired  Steering  and  Working  Groups  -  The  IPT  may  be  directed 
by  the  lead  MAJCOM,  or  may  want,  to  establish  some  steering  or  working  groups  to  help  direct,  manage, 
or  execute  some  of  the  PC/ALC  assigned  Phase  0  responsibilities.  Some  examples  of  groups  the  IPT 
might  establish  during  Phase  0  are  the  Test  Planning  Working  Group  (TPWG),  Threat  Working  Group 
(TWG),  Supportability  Working  Group  (SWG),  and  the  Computer  Resources  Working  Group  (CRWG). 
See  023  for  more  information  on  these  and  other  groups. 

7.  DESCRIPTION: 

a.  Updating  the  Phase  0  Plans  -  Upon  the  compl^ion  of  the  Milestone  0  reviews  arxl  MDA 
approval  of  concept  study  efforts,  the  MDA  issues  an  ADM  (see  A9  and  B9).  After  receipt  of  the  ADM, 
USAF/XOR  completes  and  issues  the  Phase  0  PMD  (see  BIO).  The  lead  MAJCOM  must  ensure  the 
previously  developed  Phase  0  plans  (see  Cl  4,  D20A,  and  D20B)  satisfy  the  direction  provided  by  the 
ADM  arKf  the  PMD,  as  issued.  If  the  IPT  was  actively  involved  through  the  lead  MAJCOM  with  the 
drafting  of  the  ADM  and  PMD,  and  proactive  at  addressing  issues  raised  throughout  the  milestone  review 
process,  there  should  be  no  surprises  regarding  the  content  of  either  document.  In  this  case,  the  draft 
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plar»  developed  during  the  milestone  review  process  should  need  little  or  no  modification  and  may  be 
ready  for  iminediate  implementation.  After  any  needed  modifications  have  been  completed,  final 
coordination  is  obtained  from  all  participating  organizations,  and  final  approval  of  the  piarrs  is  made  by 
the  appropriate  approval  authority,  as  established  by  the  lead  MAJCOM. 

Upon  final  approval,  the  plans  are  baselined  and  used  by  the  PC/ALC  and  all  supporting 
organizations  as  the  basis  for  executing  and  controlling  assigned  Phase  0  activities.  Given  PC/ALC 
Commander  go  ahead  (see  079),  the  IPT  will  begin  to  execute  the  tasks  in  the  manner  approved  by  the 
plans.  Throughout  the  execution  of  Phase  0,  changes  in  direction,  strategy,  resources,  etc.,  must  be 
monitored  and  evaluated  by  the  IPT  and  appropriate  participating  organizations  for  their  impact  to  the 
baseline  plans.  For  significant  changes,  the  plans  may  need  to  be  reworked,  recoordinated  and 
approved,  and  then  rebaselined. 

b.  Establishing  Steering  and  Working  Groups  -  During  the  milestone  review  process,  the  IPT 
should  have  begun  organizing  the  resources  needed  to  achieve  the  PC/ALC  assigned  Phase  0 
objectives.  This  activity  includes  the  identification  and  establishment  of  any  desired  or  required  steering 
and/or  working  groups.  Steering  and  working  groups  are  one-time,  periodic,  or  on-going  activities  which 
pull  together  appropriate  management  and/or  technical  expertise  to  direct,  assist,  guide,  or  execute  an 
assigned  task.  Steering  groups  are  typically  formed  to  provide  management  oversight,  guidance, 
advice,  or  approval  authority  for  specified  activities.  Working  groups  are  typically  formed  to  manage  artd 
execute  a  specified  task.  Any  number  of  these  groups  may  be  formed  at  IPTs  discretion  to  support  their 
accomplishment  of  assigned  Phase  0  responsibilities;  however,  some  groups  may  be  directed  by  the 
PMD  or  other  authority.  See  023  for  some  examples  of  technical  working  groups  typically  established  at 
the  PC/ALC  level. 

8.  ENTRANCE  AND  EXIT  CRITERIA: 

a.  Entrance  Criteria 

Concept  Studies  Approval  -  When  the  Milestone  Decision  Authority  (MDA)  is  satisfied 
with  the  MNS  and  any  requested  Phase  0  planning  information,  approval  is  given  to  proce^  with  Phase 
0  concept  studies.  The  MDA  will  issue  an  ADM.  and  AF/XOR  will  issue  a  PMD.  After  receiving  these 
documents  the  lead  MAJCOM  will  update  Air  Force  Phase  0  plans  as  required  to  bring  them  in  line  with 
the  guidance  provided  by  the  ADM  and  PMD.  The  PC/ALC  will  update  their  plans  and  forward  them  to 
the  lead  MAJCOM  for  review  and  approval,  and  inclusion  in  the  Air  Force  plans,  as  appropriate. 

b.  Exit  Criteria 

(1 )  Phase  0  Plans  Updated  and  Approved  -  After  receiving  the  PMD.  the  lead  MAJCOM 
will  ensure  all  Air  Force  Phase  0  plans,  including  those  developed  by  the  PC/ALC,  are  updated  as 
required  to  bring  them  in  lirte  with  the  direction  provided  by  the  ADM  and  PMD.  Once  final  approval  is 
made  by  the  designated  approval  authority,  the  plans  are  baselined  and  then  executed. 

(2)  Steering  and  Working  Groups  Established-  If  the  PC/ALC  approved  Phase  0  plans 
identify  the  need  or  desire  for  any  management  or  technical  support  groups,  charters  should  be  drawn  up 
and  approved  by  the  PC/ALC  to  formally  establish  them. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Key  Inputs 

(1 )  Program  Management  Directive  (PMD)  (see  BIO)-  The  PMD  is  the  official  Air  Force 
document  used  to  direct  acquisition  or  modification  resportsibilities  to  appropriate  Air  Force  MAXOMs 
for  the  development,  acquisition,  or  modification  of  a  specific  weapon,  subsystem,  or  piece  of 
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equipment.  The  Phase  0  PMD  is  issued  by  USAF/XOR  and  wiH  minimally  accomplish  the  following  for 
Phase  0: 


Designate  the  lead  MAJCOM. 

Identify  and  direct  all  participating  organizations. 

-  Identify  the  MAXOM  responsible  for  establishing  the  CAG  (if  required)  and  for  leading  the  concept 
studies. 

-  Identify  funding  sources  and  approved  study  alternatives. 

-  Briefly  address  the  purpose,  study  recfoirements.  required  documentation,  and  schedule  considerations 
for  the  Milestone  I  (MS  I)  decision. 

-  Establish  Air  Staff,  SAF,  Joint  Staff,  and  OSO  review  and  coordination  procedures  for  an  MS  I  decision. 

The  Phase  0  PMD  will  incorporate  and  expand  on  the  direction  provided  by  the  ADM.  It  is  required  by 
the  lead  MAJCOM  and  other  participating  organizations  to  identify  the  fonding  source  and  amount  and 
justify  the  further  expenditure  of  resources  for  the  planrted  Phase  0  activities. 

(2)  Draft  Phase  0  Plans  (see  C14.  D20A.  and  D20B)  ■  These  are  the  draft  plans 
developed  by  the  lead  MAJCOM  and  the  PC/ALC  prior  to  the  milestone  decision.  These  plans  provide 
the  following  information  that  must  be  updated  to  account  for  PMD  direction; 

-  Phase  0  purpose,  objectives,  constraints,  and  assumptions. 

-  The  propos^  strategy  and  organization  for  accomplishing  assigned  Phase  0  responsibilities. 

-  Identification  of  all  tasks  required  to  complete  assigned  Phase  0  objectives. 

-  Schedule  estimates  with  exit  criteria  for  completing  assigned  Phase  0  objectives. 

-  Estimates  of  required  resources  needed  to  complete  assigned  Phase  0  objectives. 

The  PC/ALC  and  the  lead  MAJCOM  must  ensure  that  this  information,  ard  all  organizational  plans  based 
upon  it,  are  consistent  with  the  Phase  0  ADM  and  PMD  direction. 

(3)  Updated  Technical  Planning  (see  D23}  •  The  technical  planning  information 
developed  in  D23  is  a  sub-set  of  the  planning  updates  being  accomplished  by  this  activity.  The 
information  developed  from  that  activity  should  be  treated  as  an  integral  part  of  this  activity. 

(4)  Task  Go-Ahead  from  PC/ALC  Commander  (see  D79)  -  Each  PC/ALC  involved  in  the 
Phase  0  activities  should  have  established  Center  processes  for  reviewing  and  approving  new  work. 
Typically,  this  review  culminates  in  the  CommarxJers  written  or  verbal  approval  to  experd  manpower  and 
resources  for  the  work  in  question. 

b.  Key  Outputs; 

(1 )  Approved  Phase  0  Plarts  -  After  the  PC/ALC  and  all  of  their  sup|x>rting  organizations 
have  accounted  for  PMD  direction  and  have  updated  and  coordinated  Phase  0  plans,  the  they  will 
forward  the  documented  PC/ALC  planning  position  to  the  lead  MAJCOM  for  approval.  Once  approved, 
these  plans  become  the  baseline  for  PC/ALC  management  ard  control  of  the  Phase  0  activities. 

(2)  Steering  and  Working  Group  Charters  -  Each  steering  or  working  group  formed  by 
the  PC/ALC  should  have  a  charter  approved  by  the  PC/ALC  which  identifies  the  groups'  functions, 
responsibilities,  organization,  and  membership,  and  the  roles  and  responsibilities  for  the  membership 
within  the  group.  This  charter  should  have  ties  back  to  the  PMD  ard  provde  all  of  the  necessary 
direction  the  group  needs  to  operate.  The  charter  rmst  be  defined  in  enough  detail  to  distinguish  the 
responsibilities  of  the  steering  or  working  group  from  the  responsibilities  of  the  other  Phase  0 
participants. 


•  • 


D-335 


Mwn 


ia  KEY  REFERENCES: 

-  OoO  Oiractivs  5000.1 ,  23  Feb  91 .  ’Defense  Acquisition,*  provides  overali  DoO  defend  acquisition 
policies. 

-  DoD  Instiuction  5000.2, 23  Feb  91 ,  ’Defense  Acquisition  Management  Policies  and  Procedures,’ 
Section  E,  paragraph  2,  provides  DoD  policies  on  program  plans. 

■  AFMC  Pamphlet  800-60,  31  Mar  93,  ’IrMegr^ed  Weapon  System  Management  (IWSM)  Guide,’ 
describes  AFMCs  IWSM  philosophy  and  provides  guidance  and  evolving  processes  for  implementirtg 
this  philosophy. 

■  AFMC  Pamphlet  800-52, 4  Dec  92,  ’Acquisition  Risk  Management  Guide  (Preliminary),’  identifies 
potential  risk  areas  and  tools  and  techrtiques  for  risk  management. 

-  AF  Policy  Letter  91M-001 . 20  Jun  91 ,  ’Early  Irxlustry  Involvement  in  Acquisition  Planning,’  establishes 
SAF  policies  regarding  early  Industry  involvement  in  acquisition  plannirx). 

■  AFMCR  500-18,  ’Commanders  Policy  -  Systems  Representative  (SYREP),’  describes  AFMCs  policies 
regarding  the  role  of  the  SYSREPs  and  the  acquisition  teams  interface  with  them. 

11.  PLANNN4G  GUIDANCE: 

a.  DURATION: 

(1 )  Updating  Phase  0  Plans  -  Assuming  the  ADM  and  PMD  contain  no  suprises,  the 
PC/ALC  should  allot  at  least  2-4  weeks  to  complete  and  obtain  final  coordination  and  approval  of  the 
Phase  0  plans.  If  the  ADM  and  the  PMD  cause  significant  changes  to  the  Air  Force  planning  position,  or 
add  unexpected  requirements  or  participants,  considerably  more  time  will  typically  be  required  to  account 
for  these  changes.  If  the  lead  MAJCOM  is  anticipatirrg  such  changes,  for  whatever  reason,  an  additional 
2-4  months  is  lAely  a  better  planning  estimate  for  final  Phase  0  planning  approval. 

(2)  Establishing  the  Steering  and  Working  Groups  -  Developing  the  Charter  for  each  of 
the  steering  or  working  groups  can  typically  be  accomplished  in  less  than  1  -week.  Formal  coordination 
and  approval  of  the  Charter  could  take  several  weeks  to  several  months,  depending  on  the  number  of 
organizations  involved.  In  most  cases,  these  groups  should  begin  to  execute  their  responsbilities  as 
soon  as  required.  The  formal  approval  of  the  Charter  shoukkil  necessarily  delay  their  start. 

b.  CONSTRAINTS: 

(1 )  PMD  Direction  -  The  direction  provided  by  the  PMD  must  be  satisfied  by  the  Phase  0 

plans. 


c.  RESOURCES: 

(1 )  Updating  Phase  0  Plans  -  The  IPT  formed  to  develop  the  Phase  0  plans  (see  D20A) 
should  provide  aH  the  resources  required  to  update  the  plans. 

(2)  E&ablishing  Steering  and  Working  Groups  -  The  PC/ALC  should  identify  at  least  one 
individual  to  ensure  each  necessary  group  is  appropriately  established  with  a  formally  coordinated  and 
approved  Charter.  Each  group  formed  may  require  specific  technical  expertise  from  several  functional 
(Splines. 


(3)  Funding  -  Sufficient  funding  should  be  made  available  to  allow  necessary  and 
appropriate  travel  for  collecting  and  coordinating  planning  inputs  from/with  participating  organizations 
and  developing  steering/working  group  Charters. 

d.  LESSONS  LEARNED: 

(1 )  Updating  Phase  0  Plans  -  None  Identified. 
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(2)  Steering  wnd  Working  (^oups  •  None  Identified. 

e.  BEST  PRACTICES: 

(1)  Updatirtg  Rtase  0  Plans  •  None  UierMed. 

(2)  Steering  and  Working  Groups  -  None  Identified. 

f.  TRAPS: 

(1)  (Updating  Phase  0  Plans 

(a)  PMD  Direction  -  The  direction  provided  by  the  PMD  should  not  be  left  open 
to  interpretation.  If  you  have  any  question  regarding  the  intent  of  any  information  provided  by  the  PMD 
get  it  clairified  before  acting  upon  it. 

(2)  Steering  and  Working  Groups -Hone  Identified. 

12.  IMPLEMENTATION  TOOLS:  None  Identified. 
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1.  ELEMENT:  D23.  TBS  1.1 .4.3  (IFC  93-3) 

2.  ELEMENT  TITLE:  Updftte  Technical  Plans  (AFMC  Centers) 

3.  ELEMENT  OWNER(S):  Project  Cadre;  Product  Center  Program  Development  Team  (ASC/YX  at 
ASC) 

4.  ELEMENT  STAKEHOLOE(S): 

a.  Implementing  (System  Program  Oirector/Product  Group  Manager/Material  Group  Manager  - 
SPD/PGM/MGM)  &  Operating  Commands 

b.  Product  Center  XRs 

c.  Laboratories 

d.  AFMC  Functionals 

e.  Air  Staff  Functionals,  (e.g.  XO,  LG,  IN,  00,  etc.) 

f.  SAF/AQ 

g.  Intelligence  Agencies 

h.  Industry 

5.  REQUIREMENTS: 

a.  DODI  5000.2,  Defense  Acquisition  Management  (DAM)  Policies  &  Procedures,  Jan  91 ; 

(1)  Part  4,  Requirements  Evolution  and  Affordability,  Sections  A  &  B,  and 

(2)  Part  1 1 ,  Program  Control  and  Review,  Sectbns  C,  D  &  E,  Review  plans,  procedures 

and  reports: 

b.  AF  Sup  1/DODI  5000.2,  DAM  Policies  &  Procedures,  Sep  92,  Parts  4  thai  9; 

c.  AF1 1 0-601 ,  Mission  Needs  &  Operational  Requirements  Guidance  &  Procedures,  Feb  93, 
Instoiction  for  developing  &  processing  AF  missbn  needs  and  operational  requirements ; 

d.  Military  Standard  (MIL-STD)  -  499B,  Systems  Engineering,  Draft  May  92,  Section  3.8, 
Systems  Engineering  Process. 

6.  PURPOSE  /  OBJECTIVE(S): 

a)  Purpose;  To  update  technical  plans  and  initiate  government  development  activities  for 
identified  preliminary  system  concepts  for  Phase  0  in  support  of  the  Operating  Ck>mmand,  in  accordance 
with  the  Program  Management  Directive  (PMD). 

b)  Objective(s);  To  complete  or  initiate  the  following  tasks  that  will  support  the  PC/ALC  Phase  0 
activities: 
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(1 )  Complete  government-level  updates  to  technical  plans  development,  such  as:  S 

(a)  Government-level  Systems  Engineering  Master  Plan  (SEMP). 

(b)  Program  Protection  Plan  (PPP). 

(c)  Logistics  Support  Analysis  (LSA)  Strategy. 

(d)  Concept  studies  and  analysis  activities 

(2)  Complete  the  definition  of  Phase  0  technical  tasks  and  their  interfaces  by  functional  • 

discipline  for  cooperative  government  and  industry  activities: 

(a)  Traditional  Engineering  (such  as  electronics,  aerodynamic,  etc.). 

(b)  Speciatty  Engineering  (such  as  logistics,  maintenance,  etc.). 

(c)  Test  Engineering. 

(d)  Production  Engineering. 

(e)  Studies  and  Analyses.  0 

(f)  Security. 
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(3)  Update  or  establish  specific  worfcing/steering  groups  to  initiate  development  of: 

(a)  references  such  as  the  Baseline  CkxKept  Descriptions  (BCDs). 

(b)  strawman  System  Requirements  Document  (SRD). 

(c)  computer  resources. 

(d)  threat  information. 

(4)  Develop  strawman  System  Engineering  Master  Schedule  (SEMS). 

(5)  Develop  draft  COEA  f  plan. 

7.  DESCRIPTION: 

The  overall  goal  is  to  provide  a  complete  package  for  the  techrucal  needs  and  activities  to  be 
covered  during  Phase  0.  This  technical  activity  is  the  first  opportunity  following  the  Milestone  (MS)  0 
decision  for  the  government  team  members  to  review  and  update  the  technical  areas  (see  D20B)  of 
significant  activity  for  Phase  0.  This  is  the  point  where  the  project  manager  must  assemble  an 
Integrated  Product  Team  (IPT)  that  starts  putting  definitive  structure  and  content  into  the  developments 
and  assessments  of  the  concepts  to  be  explored.  Cooperation  between  this  activity  and  D22  is  important 
for  this  and  foliowing  integration  efforts.  The  IPT  is  a  precursor  to  the  Project  Cadre.  Coordination  and 
participation  among  the  stakeholders  is  very  important  to  ensure  consistent  perspectives,  understandings 
arKf  commitments  for  the  tasks,  resources  and  schedule. 

The  Project  IPT  should  make  any  updates  to  the  plans  as  required  by  the  Acquisition  Decision 
Memorandum  (ADM)  document.  One  area  of  focus  is  the  specific  government  activities  to  be 
conducted.  The  technical  plans  and  tasks  for  both  government  and  contracted  resources  must  be 
completed.  Working  groups  should  be  continued  or  established  to  initiate  the  development  of  key 
references  such  as  BCDs,  the  SRD,  and  the  system  threat  assessement  report  (STAR).  Initial  studies  by 
the  Project  IPT  will  update  the  SEMP,  expand  the  BCDs  and  the  SRD,  and  document  assumptions  and 
groundmles  for  the  technical  analyses.  An  outline  for  a  draft  COEA  I  plan  is  also  defined.  Particular 
attention  should  be  given  to  defining  the  scope  of  the  anticipated  CO^  activities  by  the  number  of 
concept  alternatives  to  be  evaluated.  Most  of  these  developments  and  updates  are  fed  into  the  project 
datab^  (D31 ),  which  will  make  the  data  available  for  the  concept  exploration  to  be  performed  in  D37. 
Some,  such  as  key  reference  documentation  like  the  SRD  and  COEA  I  outlines,  are  passed  to  the 
Operating  Command  for  their  development  package. 

8.  ENTRANCE  /  EXIT  CRITERIA: 

a.  Entrance:  The  activitiy  is  initiated  when  the  Operating  Command  receives  the  approval 
through  an  Acquisition  Decision  Memorandum  (ADM)  and  a  Program  Management  Directive  (PMD). 

The  Operating  Command  will  update  their  Phase  0  plans  and  request  similar  feedback  from  the  selected 
PC/ALC. 

b.  Exit:  Operating  Command's  approval  of  the  Project  IPTs  plans  and  established  technical 
baseline. 

9.  KEY  INPUTS  /  OUTPUTS: 

a.  Key  Inputs: 

(1)  Draft  Functional  Plans  •  (D20B) 

(a)  Initial  SEMS  (Systems  Engineering  Master  Schedule), 
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(b)  Strawman  SEMP  (Systems  Engineering  Managennent  Plan), 

(c)  Initial  ILSP  (Integrated  Logistics  Support  Plan), 

(d)  Updated  LSA  (Logistics  Support  Analysis)  Strategy. 

(e)  Initial  TEMP  (Test  and  Evaluation  Master  Plan), 

(e)  Strawman  PPP  (Program  Protection  Plan). 

(2)  Work  Statements  -  (020B  &  D34)  -  the  PC/ALC  identifies  all  (technical)  activities 
that  will  be  required  to  successfully  accomplish  Phase  0  objectives.  These  cover  both  government  arxf 
industry  tasks,  along  with  the  timeframe  of  their  execution.  Coordination  with  the  Operating  Command 
draft  plans  ( C14)  is  important. 


(3)  Strawman  BCD  (Baseline  Concept  Document)  -  (D20B). 

(4)  Summaries  from  prior  steering  groups  for  threat,  concepts,  etc. 

b.  Key  Outputs: 

(1)  Technical  Analysis  Plans  for  Government  and  Contracted  Activities  (D22  &  D31). 

(2)  Draft  SRDs  (Cl 9). 

(3)  Draft  BCDs  (C19). 

(4)  Draft  COEA  I  Plan  (D31). 


10.  KEY  REFERENCES: 

a.  AFPD  10-6,  Operational  Requirements.  Jan  93,  Policy  directive  for  implementing  the  mission 
needs  and  operational  requirements  developments; 

b.  DOD  5000.2-M,  Part  1  &  following,  Feb  91 ,  Procedures  and  formats  to  be  used  for  various 
milestone  documentation. 

c.  AF  Sup  1/  DODI  5000.2,  Acquisition  Management  Policies  &  Procedures.  Sep  92.  Part  2, 
Section  B,  Policies  for  interface  management. 

d.  MtL-HNBK-499-3,  System  Engineering  /  Configuration  Management  (SE/CM)  -  Life  Cycle 
Application,  Draft  Aug  92. 

e.  MtL-STD-1388-1 A,  Logistic  Support  Analysis  (LSA),  Apr  83,  provides  general  requirements 
and  task  descriptions  for  performance  of  LSA. 


11.  IMPLEMENTATION  TOOLS: 

a.  ASC/YX  Program  Development  Process  Product;  these  include  a  process  flow  chart,  a 
process  checklist  and  a  process  ^ide  (see  D20). 

b.  Air  Force  Acquisition  Model;  an  AFMC  managed  acquisition  tool. 

c.  MIL-HNBK  499-3;  process  guide. 
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d.  Outline  from  APR  800-3,  Aa)uisition  Management,  Engineering  for  Defense  Systems, 

17Jun  77. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  •  This  activity  will  typically  take  2-3  months  for  a  full  system  deficiency  or  4-6 
weeks  tor  a  major  subsystem  or  component.  This  assumes  that  some  input  has  been  develop^  tor 
these  activities  during  the  efforts  prior  to  MS  0.  Aspects  that  could  lengthen  the  timeframe  include 
number  of  organizations  involved,  particularly  across  PC/ALCs  joint  service  or  international 
involvements,  and  political  sensitivities. 

b.  CONSTRAINTS:  PMD  guidance/direction  and  the  subsequent  impact  on  Phase  0  plans. 

c.  RESOURCES:  Typically  15-20  key  persons  from  the  PC/ALCs  for  a  full  system  assessment 
and  6-10  for  a  major  subsystem  or  component.  This  activity  is  preferably  performed  by  an  integrated 
product  team  (IPT),  involving  all  principal  stakeholders  and  participants  of  Phase  0. 

d.  LESSONS  LEARNED: 

(1)  The  technical  planning  should  consider  the  synergy  from  cooperative  government 
and  industry  efforts  for  Phase  0.  Often,  the  government  resources  and  capabilities  can  be 
complemented  by  those  available  through  contracted  efforts.  T.his  adds  additional  emphasis  on 
maintaining  close  ties  to  industry  to  allow  effective  interfaces  at  key  points  in  the  overall  developments. 
At  this  stage,  it  also  gives  a  heads-up  to  the  potential  industry  participants. 

(2)  The  technical  OPR  should  look  for  active  participation  from  all  team  members. 
Particular  attention  should  be  given  to  those  functional  areas  that  have  direct  connection  to  the  type  of 
need  being  addressed.  This  is  not  just  a  passive  exercise;  the  team  members  should  be  effectively 
"committing''  the  identified  resources. 

(3)  It  is  crucial  that  these  updates  and  initial  activities  be  communicated  with  and 
approved  by  the  Operating  Command.  The  approach  used  throughout  AFMC  is  to  utilize  the  SYSREP 
(AFMC  representative  physically  located  at  the  MAJCOM,  usually  with  the  Plans  and  Programs  or 
Requirements  offices,  i.e.  /XP  or  /DR)  as  a  means  of  keeping  the  information  exchange  a  dynamic 
process. 

e.  BEST  PRACTICES: 

(1)  A  core  IPT  with  actual  experience  from  the  Pre-MS  0  activities  is  the  preferred 
approach.  This  will  ensure  a  nrare  consistent  perspective  being  maintained  and  also  that  nothing  is  lost 
during  the  transition.  Accepting  the  fact  that  some  turnover  will  always  occur,  documentation  becomes 
important  (see  D15). 

(2)  Attention  should  be  given  to  keeping  the  most  important  (key)  functional  area 
representarives  as  members  of  the  IPT.  Corporate  menwry  is  not  easily  recovered  or  reconstructed, 
even  with  documentation. 

(3)  It  is  important  to  periodically  review  the  original  factors  that  evolved  during  the 
development  of  the  MNS,  ADM  and  PMD.  These  are  the  main  drivers. 

f.  TRAPS: 

(1)  It  is  difficult  to  identify  a  single  point  where  plans  are  updated  and  concept 
developments  are  initiated. 
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(2)  External  influences  can  have  an  effect  on  the  plans  at  this  stage.  Updated  plans  for 
Phase  0  should  emphasize  maintaining  an  open  and  broad  perspective  for  evaluating  the  identified  set  of 
altematives.  Maintain  caution  about  the  'right*  solution  sneaking  into  the  process. 

(3)  Small  project  teanrts  with  limited  representation  are  often  faced  (knowingly  or  not) 
with  having  to  pursue  activities  that  are  supportable  only  through  contracted  efforts.  Too  often  this 
contracted  approach  is  the  preferred  choice,  even  when  there  are  adequate  resources  available  to 
effectively  organize  an  in-house  team.  It  is  vitally  important  that  the  IPT  fully  exercise  this  planning 
function  and  seriously  address  the  coricept  of  an  in-house  team  for  paralleling  the  efforts  performed  by 
industry. 
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2.  ELEMENT  TITLE:  Explore  Use  of  Nondevelopmental  Kerns  (NDI) 
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3.  ELEMENT  OWNER(S):  The  Office  of  the  Assistant  Secretary  of  Defense  for  Production  and 
Logistics  (OASD  (P&L)  SDM)  is  charged  wKh  overseeing  DoO  activity  as  K  relates  to  NDI  procurement. 

4.  ELEMENT  STAKEHOLOER(S):  Developing  Project  Office,  Operating  Command,  Air  Force 
CompetKion  Advocate,  The  Deputy  Under  S^retary  of  Defense  for  AcquisKion  Reform 
(OSD/DUSD(AR)). 

5.  REQUIREMENT: 

a.  DODI  Directive  5000.1 ,  Defense  AcquisKion,  Part  1 ,  page  4,  Para  1  .c,  23  Feb  91 ,  states 
maximum  practicable  use  shall  be  made  of  commercial  and  other  nondevelopmental  Kerns.  In 
describing  these  Kerns,  maximum  practicable  use  shall  be  made  of  nongovernment  standards  and 
commercial  Kem  descriptions. 

b.  DODI  5000.2,  Deferrse  AcquisKion  ManagemerK  Policies  ard  Procedures,  Part  6,  Section  L; 
Part  6,  Section  H,  para  3.a.(3);  Part  3,  page  3-11;  and  Part  10,  Section  C,  para  2.d,  Nondevelopmental 
Kerns,  23  Feb  91 ,  states  policies  and  procedures  which  establish  the  basis  for  cost-effective  use  of 
commercial  products  atxf  other  non-developmerKal  Kerns  in  defense  systems  and  equipment. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  purpose  of  this  element  is  to  explore  purchasing/using  existing  v.oducts  or 
systems  rather  than  pursuing  development  of  new  Kerns. 

b.  Objectives:  Explore  existing  or  emerging  products/technology  that  has  potential  to  save 
IKecycle  cost  given  the  requirements  and  updated  information  at  this  program  stage.  The  following 
objectives  can  be  used  to  analyze  potential  products/technology: 

(1)  Reduced  developmental  cost 

(2)  More  rapid  fielding 

(3)  Proven  capability/reliability 

(4)  Increased  competKion 

(5)  Established  logistics  support 

(6)  Tech  data  developed 

(7)  The  Kem  is  likely  state  of  the  art 

(8)  CompetKive  Forces  have  shaped  Ks  functionalKy 

(9)  Existing  established  market 

(10)  Reduced  risk 


7.  DESCRIPTION: 

a.  This  is  an  update  to  the  work  which  went  on  in  D13  on  nondevelopmental  Kerns.  The  brief 
outline  accomplished  in  D13  is  updated  to  reflect  changes  in  the  program  including  requirements  and 
threat  assessment. 

b.  At  this  stage,  preliminary  concepts  are  being  explored  to  support  development  of  the  MNS 
Summary  (D37  and  C19).  As  part  of  this  effort,  the  Air  Force  Project  team  is  also  exploring  Cooperative 
OpportunKies  (D28)  to  update  preliminary  concepts.  The  Air  Force  will  look  at  industry's  available  off- 
the-shelf  Kerns  and  will  evaluate  them  for  satisfying  Air  Force  needs  (D29). 
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8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  A  nutterial  need  has  been  identified  and  options  need  to  be  formulated.  Also 
preliminary  performance  ranges,  thresholds,  and  trade-offs  associated  with  what  is  known  adxxit  NDI  at 
this  point  of  the  project. 

b.  Exit:  Update  NDI  information  used  in  the  concept  exploration  studies.  Also,  update  the 
preNminary  investigation  of  allemative  logistics  support. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1 )  The  project  team  requires  a  descripton  of  the  mission  need  from  the  MNS  summary. 

(2)  Market  surveillance  of  laboratories  and  the  industrial  base  through  trade  shows, 
trade  catalogs,  and  trade  magazines  is  the  primary  method  for  gaining  knowledge  of  existing  technology 
and  products  (D29).  An  updated  cost  effective  analysis  should  be  performed  on  the  item  to  find  if  it  is  a 
viable  solution  to  the  item  needed. 

b.  Outputs:  Provide  the  Operatirrg  Command  with  insight  to  potential  concept  alternatives  that 
address  his  draft  mission  need  (D37).  It  is  important  that  selected  NDI  alternatives  flow  back  into  this 
element  so  they  can  be  integrated  in  a  realistic  need. 

10.  KEY  REFERENCES: 

a.  Trtle  10  U.S.C.  2325,  Preference  for  Non-Developmental  Hems,  18  Oct  87.  This  section  of 
Title  10  mostly  describes  Congressional  mandate  to  the  Air  Force  to  look  at  and  use  NDI  in  a  weapon 
system  whertever  possible. 

b.  Proposed  Strategic  Plan  to  Pursue  Acquisition  Reform,  8  Jun  93.  Contains  draft  infonnation 
on  using  NDI  as  an  preferred  aHemative  to  developing  new  systems,  and  establishing  a  group  of 
advisors  from  OSD/DUSD(AR)  to  helo  in  NDI  procurement. 

11.  IMPLEMENTATION  TOOLS: 

a.  Trade  magazines  and  trade  shows  for  market  surveillance. 

b.  Buying  NDI/SD-2,  Oct  90.  Contact  Office  of  the  Assistant  Secretary  of  Defense  (Production 
and  Logistics),  Washington,  D.C.  20301-8000.  This  toot  mainly  describes  the  buying  process  for  NDI. 

c.  Market  Analysis  for  Non-Developmental  Items,  SD-5.  Contact  Office  of  the  Assistant 
Secretary  of  Defense  (Production  and  Logistics),  Washington,  D.C.  20301-8000.  Describes  NDI  as  an 
excellent  aHemative  to  business  as  usual. 

d.  Joint  Command  Commercial  Off-the-Shelf  (COTS)  SupportabilHy  Working  Group  (CSWG) 
Final  Report,  Jun  91 .  Contact  ASC/SDC.  Describes  the  life  cycle  concerns  of  NDI.  This  is  an  excellent 
guide  and  is  highly  recommended  to  anyone  who  is  considering  the  use  of  NDI. 


59472. 


e.  Technical  assessments  guide  for  Nondevelopmerital  Aircraft.  Contact  H.  Wood ,  ASC/ENF, 
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12.  PLANNMG  GUIDANCX: 

a.  DURATION:  You  should  start  with  the  Mission  Need  Statement  (MNS)  and  the  Government 
Sy^ems  Requiremertt  Analysis  to  get  a  handle  on  the  architecture/configuration  aftematives.  This  is  an 
ongoing  process  throughout  Pre-Milestone  0  to  Milestone  I  and  will  vary  in  duration  depending  on 
complexity  of  the  identified  mission  need. 

b.  CONSTRAINTS:  As  always,  timing  is  a  major  constraint.  If  an  NDI  is  selected  early,  it  may 
become  obsolete  and  out  of  production  by  the  time  the  weapon  system  is  fielded.  You  have  limited  data 
rights  with  NDI,  no  configuration  control,  and  no  existing  AF  support  structure. 

c.  RESOURCES:  All  functiorral  areas  need  to  be  involved  in  NDI.  Much  of  their  involvement 
will  be  in  the  requirements  area.  There  will  be  a  low  level  of  man-hours  with  NDI  at  this  stage  of  the 
project.  Most  of  the  man-hours  will  be  put  into  the  very  important  requirements  area  so  that  realistic 
requirements  levels  will  be  explored  and  a  better  selection  of  NDI  will  be  made. 

d.  LESSONS  LEARNED:  There  were  seven  lessons  learned  in  the  Automated  Lessons 
Learned  Capture  and  Retrieval  System  (ALLCARS)  data  base.  The  numbers  are  1449, 20009, 20012, 
20016, 20045, 20047,  20084.  These  items  all  deaK  with  logistical  support  problems  and  problems  with 
sBghtly  modified  NDI  items.  Therefore,  pay  special  attention  to  these  areas  when  considering  NDI. 

e.  BEST  PRACTICES:  If  NDI  is  not  considered  at  the  early  stages  of  the  acquisition  cycle  then 
you  probably  will  not  be  able  to  acquire  it  as  a  NDI  item  later. 

f.  TRAPS:  Not  taking  the  follow-on  support  and  possible  added  life  cycle  costs  into  account 
when  using  NDI.  Too  much  modification  usually  negates  any  life  cycle  cost  savings.  A  military 
application  of  NDI  may  have  a  significantly  different  operating  environment  and  usage  than  experienced 
in  commercial  applications  which  may  impact  the  operational  characteristics,  performance,  and  useful 
life  of  the  item.  A  through  technical  evaluation  should  be  accomplished  to  avoid  unacceptable  risk. 
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1.  ELEMENT:  D28.  TBS  1.2. 1.4  (IFC93-3) 

2.  ELEMENT  TITLE:  Explore  Cooperative  Opportunities  (CO) 

3.  ELEMENT  OWNER(S):  Deputy  Under  Secretary  of  Defense  (International  ProgratTis)(DUSD(IP)), 
Assistant  Under  Secretary  of  Defense  for  Programs  &  Acquisition  (USDA(P&A)),  SAF/AQXI.  AFMC/IA, 
andWUXPI. 

4.  ELEMENT  STAKEHOLOER(S):  Project  Office 

5.  REQUIREMENT: 

a.  DODI  5000.2 ,  Defense  Acquisition  Management  Documentation  and  Reports.  23  Feb  91 ,  Part 
3,  pg.  3-9,  and  Part  5,  Section  F,  para  3E.  This  identifies  the  requirement  to  consider  potential 
cooperative  research  and  development. 

b.  DOD  5000.2-M  Defense  Acquisition  Management  Documentation  and  Reports,  Feb  91 ,  Part  4, 
page  4-4-1 ;  this  provides  format  for  CD. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  potential  for  international  Cooperative  Research  and  Development  of  military 
equipment  is  required  to  be  addressed  at  Milestone  0.  A  fonnal  Cooperative  Opportunities  Document 
(COD),  with  updates,  is  required  at  Milestone  I  and  beyond  (see  DODI  5000.2  for  details). 

b.  Objective:  To  determine  how  CO  can  be  applied  to  the  program.  The  first  brief  outline  of 
applicabie  Cooperative  Development  (CD)  items  is  identified  in  CD  (D14).  Now  this  list  of  CD  is 
explored  using  ujxlated  information  to  identify  usable  Cooperative  Opportunities. 

7.  DESCRIPTION: 

a.  Key  inputs  on  the  flow  chart:  Is  to  conduct  cofKept  exploration  studies  formulation  and 
evaluation  (D37),  and,  for  irxlustry  monitors  and  participates  in  government  programs,  to  exchange 
information  through  IR&D,  RFIs,  RFPs,  or  other  means  (D29).  In  this  area,  DoD's  influence  on  industry 
is  primarily  through  Small  Business  Innovation  Research  (SBIR)  and  Independent  Research  and 
Development  (IR&D)  activities.  DoD  activities  invite  small  business  firms  with  strong  research  and 
development  capabilities  in  science  and  engineering  to  subm4  proposals  under  the  SBIR  program.  The 
objectives  of  this  program  include  stimulating  technological  innovation  in  the  private  sector, 
strengthening  the  role  of  small  business  in  meeting  DoD  research  and  development  needs,  fostering  and 
encouraging  participation  by  minority  and  disadvantaged  persons  in  technological  innovation,  and 
increasing  the  commercial  application  of  DoD-sup|oorted  research  or  research  and  developm^  results. 
Exploring  use  of  Nondevelopinental  Items  (NDI)  (D27)  is  accomplished  in  a  parallel  time  frame  with  this 
effort.  NDIs  (D28)  output  is  D9,  Systems  Concept  Option  (SCO)  Formulation  and  Evaluation,  which 
provides  the  Operating  Command  with  insight  to  potential  conc^  alternatives  (such  as  CO)  that 
address  his  draft  mission  need. 

b.  The  DODI  5000.2  requirement  for  assessing  CO  mandates  the  consideration  of  buying  allied 
systems  or  cooperating  between  our  various  allies  on  development,  before  initiation  of  a  new  acquisition 
program.  A  CO  assessment  is  required  for  Acquisition  Category  (ACAT)  I  programs  and  cooperative 
opportunities  should  be  investigated  as  part  of  the  acquisition  strategy  for  ACAT  II,  III,  and  IV  programs. 
Specifically,  DODI  5000.2  specifies  an  order  of  preference  for  new  programs  as  follows: 

(1)  Use  or  modification  of  an  existing  U.S.  military  system. 
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(2)  Use  or  modification  of  an  existirtg  commefciaMy  developed  or  Allied  system  that 
foyers  a  non  developmental  acquisition  strategy. 

(3)  A  cooperative  research  and  developmeni  program  with  one  or  more  Allied  nations. 

(4)  A  new  joint  Service  development  program. 

(5)  A  new  Service-unique  development  program. 

c.  Cooperative  Development  must  be  addressed  during  this  stage  of  the  program  with  updates 
to  any  proj^m  changes  since  Milestone  0  reviews,  and  documentation  at  this  stage  wiN  be  used  in  the 
COD  at  Milestone  I. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  A  preliminary  list  of  Cooperative  Opportunities  will  be  revised  with  updated 
information  from  D37. 

b.  Exit:  Complete  exploration  studies/analysis  and  evaluation  associated  with  what  is  known 
about  Cooperative  Opportunities  at  this  point  of  the  project. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  A  deficiency  or  technological  opportunity  has  been  validated  and  prelimirtary 
requirements  have  been  outlined.  Key  inputs  on  the  flow  chart  are  D37  and  D29.  In  this  area,  DoD's 
influerK:e  on  industry  is  primarily  through  SBIR  and  IR&D  activities.  DoD  activities  invite  small  busirtess 
firms  with  strortg  research  and  development  capabilities  in  science  and  engineering  to  submit  proposals 
under  the  SBIR  program.  The  objectives  of  this  program  include  stimulating  technological  innovation  in 
the  private  sector,  strengthening  the  role  of  small  business  in  meeting  DoD  research  and  development 
needs,  fostering  and  encouraging  participation  by  mirtority  arxj  disadvantaged  persons  in  technological 
innovation,  and  increasing  the  commercial  application  of  DoD-supported  research  or  research  and 
development  results.  D27  is  accomplished  in  a  parallel  time  frame  with  D28. 

b.  CXitputs:  An  updated  list  of  potential  CO  systems  or  a  determination  if,  at  this  stage  of  the 
program,  CO  is  viable.  This  will  then  feed  into  D37  to  update  the  Concept  Exploration  Studies. 

10.  KEY  REFERENCES: 

a.  HQ  AFMC/XT  Letter,  9  Mar  92,  Development  Ranning  Relationship  to  International 
Opportunities.  This  shows  how  CO  is  integrated  into  the  program  life  cycle. 

11.  IMPLEMENTATION  TOOLS:  None  identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  arrK>unt  of  time  needed  to  accomplish  this  activity  is  dependent  upon  the 
complexity  of  the  Hem.  Forty  man-hours  of  the  project  management  team  should  be  more  than  erxHjgh 
time. 


b.  CONSTRAINTS: 

(1)  Time  and  money  in  investigating  various  alternatives. 

(2)  Lack  of  a  central  location  to  obtain  needed  information  on  existing  and  planned 
milHary  and  aflied  nation  projects. 

c.  RESOURCES:  Not  much  time  is  needed  at  this  point  of  the  program.  Forty  man-hours  for 
project  office  personnel  should  be  more  than  erKXjgh  for  a  program  of  any  complexity. 
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d.  LESSONS  LEARtiCO:  There  are  ik)  lessons  learned  in  the  Automated  Lessons  Learned 
Capture  and  Retrieval  System  (ALLCARS)  database  on  this  item. 

e.  BEST  PRACTICES: 

(1)  Start  as  early  as  possible  compiling  information  on  U.S.  and  aUied  programs  which 
should  be  evaluated  for  joint  program  applicability.  Consideration  to  buy  or  cooperate  at  or  near  the 
Milestone  I  decision  is  too  late  to  effectively  pursue  overseas  opportunities.  Consideration  of  overseas 
opportunities  must  begin  during  development  planning  or.  tor  technology  push,  be  an  outgrowth  of 
ongoing  S&T  cooperation.  Therefore,  it  is  important  to  begin  early  to  investigate  the  various  alternatives 
dealing  with  cooperative  development  programs. 

(2)  The  Defense  Acquisition  Board  (DAB)  will  be  much  more  inclined  to  hold  up 
programs  that  have  not  identified  ways  to  reduce  costs  to  the  U.S.  taxpayer  through  cooperation. 

(Donald  Yockey,  Principal  Deputy  Under  Secretary  of  Defense  for  Acquisition;  Appearance  before  the 
Senate  Armed  Services  Committee,  1 2  Jun  1990).  This  analysis  should  be  done  to  assist  in  making  a 
decision,  not  just  to  fill  out  the  paper  work! 

I.  TRAPS:  Doni  forget  to  establish  early  a  comprehensive  protection  and  technology  control 
program  to  identify  and  protect  classified  and  other  sensitive  information. 
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1.  ELEMENT:  029.  TBS  0.1 .3.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Industry  Monitor  and/or  Participate  in  Qoverrvnent  Programs  through  IR&D,  RFI, 
RFP,  or  other  means 

3.  ELEMENT  OWNERS:  Protect/Program  Manager  (PM)  and  Procurement  Contracting  Officer  (PCO). 

4.  ELEMENT  STAKEHOLDERS:  Industry  and  Project/Program  Team. 

5.  REQUIREMENT: 

a.  Department  of  Defense  Instruction  5000.2 

b.  Defense  Acquisition  Management  Policies  and  Procedures.  23  Feb  91 ; 

(1)  Part  5,  Section  A.  paragraph  3c 

(2)  Section  E;  Part  10 

(3)  Section  C,  paragraph  2e 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose;  The  overall  purpose  of  this  data  sheet  is  to  provide  a  single  reiurence  that  explains 
the  irxkjstry  interface  across  the  spectrum  of  Pre-Milestone  I  activities.  It  summarizes  blocks  that 
interface  with  industry  and  references  them  for  specific  details.  Two  topics  that  are  not  covered  in  other 
data  sheets,  Independent  Research  and  Development  Projects  (IR&D),  and  Small  Business  Innovation 
Research  (SBIR)  activities,  are  described. 

b.  Objectives;  Through  participation  in  pre-milestone  I  activities  industry  will  gain  visibility  into 
potential  government  acquisition  activities.  This  will  allow  them  to  prepare  to  respond  to  requests  for 
acquisition  support  and  where  to  concentrate  their  efforts  for  potential  new  business  opportunities.  This 
interaction  will  also  provide  the  government  project  team  current  industrial  information. 

7.  DESCRIPTION:  The  government  interface  with  industry,  for  purposes  of  this  discussion,  is  divided 
into  three  areas;  prior  to  Milestone  0,  Milestone  0  to  Request  for  Proposal  (RFP)  preparation,  and  RFP 
to  contract  award. 

a.  Area  1 ;  Industry  Interface  Prior  to  Milestone  0;  In  this  area.  DOD's  influence  on  industry  is 
primarily  through  SBIR  and  IR&D  activities.  DOD  activities  invite  small  business  firms  with  strong 
research  and  development  capabilities  in  science  and  engineering  to  submit  proposals  under  the  SBIR 
program.  The  objectives  of  this  program  include  stimulating  technological  innovation  in  the  private 
sector,  strengthening  the  role  of  small  business  in  meeting  DOD  research  and  development  needs, 
fostering  and  encouraging  participation  by  minority  and  disadvantaged  persons  in  technological 
innovation,  and  increasing  the  commercial  application  of  DOD-support^  research  or  research  and 
development  results. 

As  a  part  of  the  overhead  on  DOD  contracts,  approximately  $8  billion  is  annually  set  aside  for  contractor 
IR&D.  While  individual  companies  control  how  their  portion  of  this  money  is  spent,  it  must  support  DOD 
efforts.  It  is  clearly  in  the  interest  of  both  the  contractors  and  the  Air  Force  that  these  efforts  work 
efficiently  toward  goals  that  will  be  of  value  to  our  programs.  Delivery  of  intormatbn  supporting  these 
goals  establishes  a  communication  link  between  Air  Force  arxf  industry,  with  the  Air  Force  providing 
insight  into  future  requirements  and  industry  providing  information  on  IR&D  projects  to  meet  those 
requirements  (see  IFC  block  D3,  Establish  Industry  Lir4<s). 


In  order  to  support  the  construction  of  the  Mission  Needs  Statement,  the  procurement  command 
prepares  a  list  of  potential  concept  alternatives  for  the  operating  command  that  addresses  the  draft 
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mission  need.  TNs  list  of  options  quantitatively  defines  the  destied  operational  and  functionai  needs  at 
the  task  level,  identifies  pretiminary  concept  alternatives  to  be  applied  against  the  draft  mission  need, 
and  provides  the  trades  and  sensitivities  data  that  relate  the  operational  requirements  to  the  system-level 
concept  approaches.  More  detailed  information  can  be  found  in  IFC  block  D9,  Develop  Preliminary 
System  Concept  Options  (SCOs). 

The  data  necessary  to  construct  the  SCO  is  developed  in  part  through  several  sub-analysis.  Public  Law 
marKlates  the  use  of  nondevelopmental  items  (NDI)  whenever  possible.  The  use  of  cost-effective 
commercial  products  and  other  nondevelopmental  items  rather  than  pursuing  development  of  new  items 
is  determined  through  an  analysis  described  in  IFC  block  D13,  Determine  Applicability  of 
Nondevelopmental  Items.  For  major  defense  acquisition  programs.  Public  Law  also  mandates  an 
analysis  of  cooperative  opportunities  early  in  the  acquisition  process.  This  analysis  considers  buying 
allied  systems  or  cooperating  on  development  before  initiation  of  a  new  acquisition  program.  The  results 
of  this  analysis  are  summarized  in  a  Co^rative  Opportunities  Document  (COD).  IFC  block,  D14, 
Determine  Suitability  of  Cooperative  Development,  explains  this  process  in  greater  detail. 

In  preparation  for  the  anticipated  Phase  1  efforts,  programmatic  and  technical  plans  are  developed  to 
support  the  lead  MAJCOM.  A  dialog  is  established  with  industry  and  the  stakeholders  at  this  stage  to 
establish  a  reasonably  accurate  technical  framework  for  the  tasks  and  other  activities  that  should  start 
after  a  positive  Milestone  0  decision.  The  objective  of  this  effort  is  to  ensure  systems  ertgineering  and 
configuration  management  philosophies  are  incorporated  into  the  project  planning  process  and  to 
complete  the  Product  &  Logistic  Centers  tasks  identified  in  IFC  block  D20B,  Draft  Phase  0  Technical 
Plans. 

b.  Area  2:  Industry  Interface  Between  Milestone  0  and  RFP:  During  this  portion  of  Phase  0, 
industry/govemment  interfaces  are  iterative  in  nature  and  assist  the  government  in  system  requirements 
development  and  concept  exploration. 

Industry/govemment  team  focuses  on  the  review  and  update  of  the  Draft  Phase  0  Technical  Plans,  with 
the  primary  objective  to  update  technical  plans  and  initiate  preliminary  system  concept  developmerrts  for 
Phase  0  in  support  of  the  lead  MAJCOM,  as  identified  in  the  Program  Management  Directive  (PMD). 
These  plans  will  provide  a  complete  outlook  of  the  technical  needs  and  activities  to  be  covered  during 
Phase  0.  The  specific  tasks  to  be  completed  are  discussed  in  IFC  block  D23,  Update  Phase  0  Technical 
Plans. 


The  industry  interface  also  focuses  on  the  Systems  Requirement  Analysis  (SRA).  The  SRA  process  is  a 
comprehensive,  iterative  system  definition  process  that  transforms  validated  customer  needs  and 
objectives  into  a  IHe-cycfe  balanced  solution  set  of  system  products  and  process  designs.  The  SRA  also 
provides  information  for  other  analyses,  feedback  to  the  customer,  and  acquisition  process  decisions.  If 
the  program  director/manager  determines  a  contractor-performed  SRA  is  required  a  contractual  vehicle 
is  pursued  as  outlined  in  IFC  bfock  D35,  Phase  0  Studies  Procurement  Activity. 

The  government  conducts  concept  exploration  studies  to  consider  all  activities  necessary  to  identify  and 
evaluate  system  requirements  and  alternative  concepts  for  satisfying  the  validated  need.  It  produces 
detailed  information  for  updating  the  technical  and  programmatic  data  bases  (established  in  Pre- 
Milestone  0  activities)  and  provides  parametric  data  for  use  in  planning  and  conducting  the  Cost  and 
Operational  Effectiveness  Analysis  (COEA).  IFC  block  D37,  Conduct  Concept  Exploration  Studies, 
explains  this  process. 

As  the  government  is  weighing  alternatives,  they  reconsider  the  use  of  NDI  and  cooperative  opportunities 
with  industry  to  meet  a  material  solution.  The  government  determines  the  suitability  of  COD  through  an 
analysis  that  allows  decision  makers  to  assess  whether  or  not  to  structure  a  program  as  a  cooperative 
development  program.  The  industry  inputs  are  used  at  defined  intervals  to  continually  update  the 
government  process  with  currently  available  technologies.  !FC  blocks  D28  and  D41  explain  the  NDI 
update  process,  and  IFC  blocks,  D28  and  D42,  provide  detailed  information  on  how  the  government 
reconsiders  cooperative  opportunKies. 
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The  preferred  COEA  alternatives  are  further  defined  and  developed.  The  corKepts  must  be  developed 
such  that  they  provide  a  sensible  balance  between  the  user's  stated  needs/requirements,  the  plann^ 
program  sch^ule  for  eventual  deployment  of  that  alternative,  and  the  estimated  cost  of  the  program 
needed  to  deploy  that  conceptual  "system."  A  cost  estimate  must  be  prepared  for  each  of  the  corKeptual 
"systems"  that  forecasts  the  program  acquisition,  operations  and  support  (O&S)  and  life  cycle  cost 
(LCC).  Operational  requirements  will  be  refiried  and  translated  into  technical  requirements  and  identified 
in  the  system  requirements  document  (SRO)  for  that  system  concept.  IFC  block  D  STB.  Concept 
Definition,  explains  this  further. 

c.  Area  3:  Industry  Interface  RFP  to  Contract  Award:  This  phase  is  defined  from  the  beginning 
of  RFP  preparation  to  contract  award.  In  this  phase  industry  is  interfacing  with  the  government  primarily 
through  the  PCO.  Industry  response  to  the  draft  RFP  is  designed  to  obtain  industry  feedbad<  on  the 
planned  acquisition.  The  draft  RFP  will  enable  industry  to  resporxl  more  effectively  in  their  proposals, 
promote  a  clearer  understanding  of  requirements,  and  aid  in  producing  a  more  effective,  quality  RFP  and 
resultant  contract.  It  also  reduces  proposal  preparation  and  evaluation  time.  More  detailed  information 
can  be  found  in  FC  block  D64,  Prepare  Request  for  Proposal  (RFP),  which  describes  the  planning  and 
preparation  of  a  solicitation,  usually  an  RFP,  from  which  industry  can  prepare  and  submit  a  proposal  for 
a  program/project. 

After  the  draft  RFP  has  been  finalized  into  the  final  RFP,  there  is  a  review/approval  process  the  RFP 
must  complete  prior  to  its  release  as  described  in  IFC  block  D69.  Release  Request  for  Proposal  (RFP). 
This  IFC  block  describes  the  process  needed  in  order  to  release  an  RFP  to  industry  from  which  they  can 
prepare  and  submit  a  proposal  in  response  to  the  requirements  of  the  program/project.  After  the  RFP 
completes  this  review  it  is  released  to  industry. 

Industry  prepares  its  proposals  which  will  be  used  as  a  basis  from  which  to  award  a  contract,  either  by 
the  formal  source  selection  process  for  competitive  acquisitions  or  by  the  negotiation  process  for 
f  noncompetitive  acquisitions.  The  purpose  of  receiving  irxkjstry  proposals  is  to  acquire  bids  from  sources 
who  could  possibly  fulfill  the  government's  requirements  at  a  fair  and  reasonable  price.  Through  source 
selection,  or  the  evaluation  process,  a  team  of  acquisition  professionals  review  the  proposals  submitted 
in  response  to  a  RFP,  and  document  the  strengths,  weaknesses,  and  risks  associated  with  each 
proposal.  From  the  results  of  the  evaluation,  the  Source  Selection  Authority  (SSA)  determines  which 
contractor  is  best  qualified  to  fulfill  the  government's  requirements  at  an  affordable  cost.  IFC  block  D70, 
Receive  Industry  Proposals  and  Conduct  Source  Selection  (Competitive)  further  explains  this  process. 

The  source  selection  and  negotiations  process  culminates  with  the  contract  award.  The  purpose  in 
awarding  the  contract  is  to  formalize  the  government's  requirements  into  a  binding,  legally  enforceable, 
contractual  vehicle  between  two  parties,  namely,  the  government  and  a  specified  contractor.  The 
corrtract  must  clearly  reflect  the  agreement  of  the  parties  and  be  consistent  with  current  law,  regulation 
and  policy.  More  detailed  information  can  be  found  in  IFC  block  074,  Award  Contract(s). 

After  a  successful  Milestone  l/IV  decision,  a  SPO  cadre  expands  into  a  SPO  in  order  to  assemble  in  a 
central  physical  location  to  accomplish  all  the  tasks  and  activities  required  during  the  remaining  phases 
of  the  acquisition.  While  SPOs  may  be  formed  to  support  a  single  program,  this  is  usually  only  the  case 
in  major,  high  priority  acquisitions.  In  the  majority  of  cases,  SPOs  are  formed  to  bring  together 
functional  expertise  which  would  be  used  to  supf^  a  number  of  smaller  similar  programs  (basket  SPO). 
The  working  relationship  with  irxfustry,  established  by  the  SPO  cadre,  should  be  reinforced  with  the 
expanding  organization.  During  this  period,  different  government  disciplines  within  the  SPO  will  be 
nurturing  working  relationships  with  their  industry  counterparts.  More  information  can  be  found  in  IFC 
block  D76,  Establish  System  Program  Office  (SPO). 

8.  ENTRANCE/EXIT  CRITERIA:  Due  to  the  nature  of  this  datasheet,  please  refer  to  the  referenced 
data  sheets  for  this  information. 


f 


# 


•  • 


D-355 


9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs:  Industry's  involvement  in  the  following  activities,  followed  by  the  required  input. 

D3  -  Future  government  requirements 

D9  -  Concept  alterruitives 

D20B  /  D23  -  Work  Statements  /  Tech  Plans 

035  -  Government  requirements  arKf  objectives 

037  -  COEA  technologies  of  interest 

037B  -  Refined  requirements  and  system  specifications 

064  -  Oraft  RFP 

069  -  RFP 

074  -  Contract 

076  -  Government  program  managers 

b.  Outputs;  Industry's  feedback  to  the  following  activities,  followed  by  the  required  output. 

09  -  Concept  alternatives 

013  /  014  -  NOI  /  Coopertative  opportunties 

O20B  /  023  -  Work  statements  /  Tech  plan  alternatives 

035  - SRA 

037  -  Contractor/Govemment  Systems  Requirements  Analysis 

027  /  028  -  NOI  /  Coopertative  opportunities  updates 

037B  -  COEA  updates,  alternative  details 

041  /  042  -  NOI  /  Coopertative  opportunties  updates 

064  -  Oraft  RFP  response 

070  -  RFP  response 

076  -  Contractor  Program 

10.  KEY  REFERENCES: 

a.  See  referenced  datasheets 

b.  ASAF(A)  Acquisition  Policy  Letter  91M-001  (20  Jun  91)  describes  the  intent  and  structure  of 
early  industry  involvement.  It  provides  a  three  phased  approach  to  teamwork  for  the  acquisition  planning 
and  RFP  process  and  also  suggests  a  number  of  methods  of  communication  by  which  the  government 
may  solicit  early  industry  involvement. 

c.  AFSC  Financial  Handbook,  Contracting,  Section  16-1 7a.  through  f. 

d.  AFMC  FARS  5335.90,  Program  Research  and  Development  Announcements  (PRDA). 

11.  IMPLEMENTATION  TOOLS: 

a.  AFSC  Request  for  Proposal  Process  Guide,  Jan  92 

b.  Electronic  Bulletin  Boards  -  electronic  capabilities  accessible  by  industry  over  common 
telephone  lines,  modem,  and  IBM  compatible  computer  can  be  used  to  index  library  information,  upload 
essential  documents  or  provide  information  in  an  expeditious  manner.  AFCC  has  established  such  a  link 
called  Helpful  Information  for  Industry  (HIFI)  which  identifies  current  and  planned  acquisition  activities. 

In  addition,  the  F-22  and  B-2  Systems  Program  Office  have  established  bulletin  board  links,  as  does 
ASC/PK,  and  ASC/CY. 
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12.  PLANNING  GUOANCE: 


a.  DURATION:  The  duration  to  initiate  an  int^stry  link  is  dependent  upon  user's  schedules, 
funding,  and  the  contracting  action  taken  to  implement  inckjstrial  studies.  If  a  task  order  contract  already 
exists,  the  effort  can  take  from  1  to  2  months  to  place  on  contract.  If  a  formal  Request  for  Proposal  is 
required,  the  effort  can  take  3  to  9  months  deposing  upon  size  of  the  project  and  the  number  of  draft 
RFP  iterations.  Once  initiated,  duration  of  the  govemment/industry  interlace  may  continue  for  years  until 
the  project  terminates. 

b.  CONSTRAINTS:  Availability  of  adequate  funding,  time,  and  schedules.  All  work  requested 
from  an  industry  participant  must  be  covered  by  a  contractual  vehicle. 

c.  RESOURCES:  Project/Program  Manager,  PCO 

d.  LESSONS  LEARNED: 

(1 )  Program  success  is  dependent  on  good  govemment/industry  team  work;  poor 
coordination  could  easily  lead  to  lack  of  understanding,  schedule  slips,  and  cost  overruns. 

(2)  Make  Use  of  Bulletin  Boards  (ESC  Jut  92)  Use  of  electronic  bulletin  boards  is  an 
effective  means  to  distribute  your  draft  RFP  documents  in  a  paperless  mode.  Rather  than  having  your 
potential  contractors  travel  to  your  location  to  obtain  a  hardcopy,  they  can  obtain  an  electronic  copy  with 
only  a  phone  call.  Put  your  ck^uments  on  the  electronic  bulletin  board  as  they  are  created-an 
incremental  draft  RFP  of  sorts.  This  allows  prospective  contractors  adequate  lead  time  for  proposal 
development  and  also  allows  for  greater  interaction  between  irxtustry  and  government. 

(3)  M  Foreign  Disclosure  (ASC  South  Jul  92)  Be  sensitive  that  early  industry 
involvement  creates  foreign  disclosure  issues.  Check  with  your  local  foreign  disclosure  office  to  ensure 
regulations  and  policy  are  being  followed. 


e.  BEST  PRACTICES:  Blanket  Notice  of  Contract  Action  (WL  Jul  92)  A  blanket  Notice  of 
Contract  Action  is  published  semiannually  to  provide  earliest  possible  notice  to  industry  of  planned 
acquisitions.  By  identifying  all  planned  activity  for  a  6  month  period,  industry  is  provided  the  opportunity 
to  form  teaming  arrangements  or  to  improve  business  decisions  in  the  use  of  limited  resources. 

f.  TRAPS: 

(1)  Limitation  to  large  contractors  and  not  reviewing  all  potential  offerors  available. 
Even  though  new  technological  advancements  are  usually  found  in  large  Research  and  Development 
organizations,  the  government  should  make  all  efforts  not  to  exclude  anyone.  All  offerors  need  to  be 
given  an  equal  opportunity.  This  should  be  handled  through  the  Small  Btusiness  Coordination  and 
synopsis  process. 

(2)  In  the  past,  lack  of  security  procedures  allowing  us  to  supply  classified  intelligence 
for  IR&D  efforts  sen/ed  as  a  roadblock  to  providing  meaningful  guidance.  Procedures  have  recently 
been  established  to  successfully  transition  data  such  as  advance  threat  list,  Air  Force  models,  test 
facilities  information,  and  6.2/6.3  laboratory  program  information  to  all  companies  working  in  a  certain 
technology.  Once  information  is  provided,  industry  can  respond  with  information  on  IR&D  projects, 
rrxxfeling,  and  test  capabilities  that  are  being  worked  in  these  technologies. 

(3)  After  RFP  release,  absolutely  no  contact  is  to  be  made  with  any  of  the  offerors 
except  through  the  PCO. 


(4)  The  tendency  of  noncontractual  team  membefs  to  woifc  oUside  the  confines  of  the 
contractual  instnjment. 
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1.  ELEMENT:  D30.  TBS  0.1. 8.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Ongoing  Laboratory  Advanced  Technology  Development,  Demonstration,  and 
Transition 

3.  ELEMENT  OWNER:  Laboratories  (principally  WL  at  ASC). 

4.  ELEMENT  STAKEHOLDERS:  Operating  Command,  Industry,  Product  Center:  Development 
Planning  (XR  at  ASC),  Program  Development  Team  (YX  at  ASC),  Engineering,  and  Project  Manager  (for 
Pre-Milestone  I,  later  referred  to  as  Program  Director  and  System  Program  Office). 

5.  REQUIREMENTS: 

a.  DoDI  5000.2,  Defense  Acquisitbn  Management  Policies  and  Procedures,  Part  5,  Acquisition 
Strategy,  Section  C,  Technology  Development  and  Derrxjnstration,  and  Section  D,  Technology 
Transition  and  Prototyping. 

b.  Local  policy  per  AFMC  and  ASC  direction  (see  references).  Successful  technology 
development  and  transition  requires  close  cooperation  between  the  technology  developers  (laboratories) 
and  the  technology  customers  (Operating  Command  and  Program  Director).  For  AFMC,  this  process  is 
overseen  by  the  Technology  Master  Process  (TMP)  and  is  implemented  at  ASC  through  the  Technology 
Transition  process,  co-owned  by  WL  and  ASC/EN. 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose;  The  timely  development,  transition,  and  application  of  technology  to  enable  the 
System  Program  Directors  to  acquire  aivf  sustain  superior  systems. 

b.  Objectives: 

(1)  Influence  the  laboratories  to  invest  their  funding  for  maximum  benefit  to  your  program. 


( 


(2)  Provide  the  laboratories  with  planning  information  as  early  as  possible  to  influence  overall 

investment  strategy.  (D5)  • 

(3)  Identify  for  the  laboratories  (and  the  operating  command)  what  technologies  the 
acquisition  program  will  need  (identified  by  the  results  of  studies  and  analyses)  from  the  laboratory 
community  to  satisfy  the  program  (and  Operating  Command’s)  requirements  (D9  and  D18). 

(4)  Influence  the  definition  of  laboratory  programs  to  develop  technologies  which  satisfy  the  D 

operating  command  requirements.  These  requirements  are  reflected  in  cost,  schedule,  and  performance 

objectives  of  the  acquisition  program  (D37  and  D43). 

(5)  Influence  the  execution  of  laboratory  programs  to  provide  transitionable,  timely,  high 
quality,  relevant,  and  cost  effective  technologies  for  the  acquisition  program's  application  (D37B  and 

D76).  • 

7.  DESCRIPTION:  The  laboratories  provide  essential  support  to  acquisition  programs  by  funding  the 
development  of  key  leveraging  technologies  not  available  from  industry.  The  Project  Manager  should 
enlist  the  laboratories  as  team  members  at  the  earliest  possible  time,  and  involvement  in  Technical 
Planning  Integrated  Product  Team  (TPIPT)  assessments  of  laboratory  programs  is  not  too  early. 

Laboratory  involvement  at  this  early  stage  enhances  the  laboratory  understanding  of  the  operating  0 

command  needs  and  allows  maximum  flexibility  in  technology  investment  strategies  that  satisfy  the 
needs.  It  also  provides  for  maximum  technology  solution  flexibility  during  later  development  phases. 
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The  flow  of  need/project/program  influence  on  the  latxjratory  program  development  and  execirtion  can 
be  summarized  as  follows: 

Pre-Phase  0:  The  TPIPTs  perform  a  the  Technology  Area  Assessment  to  influence  overall  • 

investment  strategy  (D5). 

Phase  0:  The  TPIPTs  prepare  Technology  Investment  Recommendation  Reports  (TIRRs)  and 
system  development  personnel  b^n  system  concept  development.  These  efforts  begin  to  identify 
leveraging  functional  capability  priorities  (D9/D1 8/037/043). 

Phase  0  and  later:  The  project/program  solidifies  necessary  leveraging  functional  capabilities  * 

and  begins  to  identify  application-specific  technology  solutions  (037/043/0376/076). 

a.  The  project  team  should  optimize  the  laboratory  contribution  to  the  acc^isition  program  with 
these  interfaces: 

(1)  The  Technology  Area  Assessment  (05).  Technology  Guidance  preparation  (018),  and  * 

Technology  Needs  Assessment  (043).  all  conducted  or  spor^ored  by  the  TPIPTs.  This  is  proposed  (by 

the  TMP)  to  be  the  most  influential  and  direct  operating  command  input  into  the  laboratory  planning 
process. 

(2)  Annual  operating  command  reviews,  ratings  and  ranking  of  laboratory  programs.  This  is 

currently  the  most  influential  operating  command  input  into  the  laboratory  planning  process.  * 

(3)  Oirect  involvement  of  laboratory  personnel  in  a  project/program  and/or  direct  interaction 
between  laboratory  project  managers  and  program  personnel.  Once  the  planning  process  has  responded 
to  program  rteeds.  this  is  the  area  of  highest  return  to  a  program,  by  influencing  the  laboratory  to  provide 
the  most  system-specific  technology  program  practical.  The  acquisition  project  will  need  to  participate 

with  the  laboratory  on  the  Technology  Transition  team  in  writing  the  Technology  Transition  Plan  and  • 

become  a  signatory  to  it.  The  TTP  becomes  important  to  a  system  acquisition  when  it  includes  system- 
specific  criteria  for  validation  of  technology  readiness  to  transition.  The  TTP  should  be  used  by  the 
laboratory  program  contractor  to  mature  the  technology  to  the  TTP  Transition  Criteria  requirements. 

b.  Major  interactions  between  acquisition  developments  and  the  laboratories  occur  through 

established  review  cycles.  These  opportunities  are  described  relative  to  their  host  blocks  in  the  I 

acquisition  cycle. 

(1)  Pre-Phase  0: 

(a)  At  the  outset  (D5):  One  of  the  functbns  of  the  TPIPT  process  is  to  perform  periodic 

reviews  of  laboratory  programs  through  Technology  Area  Assessments  (TAAs).  The  TAAs  are  used  by  I 

Mission  Area  Planners  and  operating  command  action  officers,  as  well  as  the  laboratories  themselves,  to 

forecast  the  technology  areas  that  should  be  addressed  by  laboratory  program  planning  to  satisfy 

operating  command  needs.  This  is  a  broad  assessment  of  overall  laboratory  thrust  areas  to  meet  all  the 

operating  command  needs  of  the  entire  mission  area  represented  by  the  TPIPT  (as  opposed  to  the  needs 

of  a  specie  system). 

(b)  Further  into  the  cycle  (D18):  The  TPIPTs  will  provide  further  guidance  to  the  * 

laboratories  in  a  Technology  Investment  Recommendation  Report  (TIRR)  and  Mission  Area 

Development  Plan.  This  guidance  is  accomplished  through  devek^ment  of  preliminary  System  Concept 

Options  and  operating  command  preparation  of  the  draft  Mission  Need  Statement  and  identification  of 

Critical  Mission  Needs  that  help  focus  technology  developments  on  functional  needs.  This  is  a  narrowing 

of  the  focus  of  laboratory  efforts  from  general  technology  areas  to  specific  functional  capabilities  that 

address  mission  needs.  I 
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(2)  Phase  0: 

(a)  Concept  Exploration  Studies  (D37)  are  used  to  kjemify  critical  technology  needs. 

The  associated  Technology  Needs  Assessment  (D43)  is  a  continuation  of  the  prior  efforts,  and  attempts 
to  influence  particular  laboratory  programs  to  address  the  specific  needs  (again,  cost,  schedule,  arxl 
performance)  of  identified  system  concepts 

(b)  The  conduct  of  Concept  Definition  for  Preferred  Altematives  (037B)  is  the  final  step 
(for  Phase  0)  in  the  solution  of  the  C^>erating  Commarxfs  needs  with  a  system  concept,  and  defines  the 
advanced  technology  needed  for  transition  and  irrtegration. 

(c)  Establishment  of  a  SPO  should  include  a  request  to  the  laboratories  for  direct  support 
in  the  form  of  a  collocated  resource  to  represent  the  labs  full  time  in  the  SPO. 

c.  Actions  that  should  be  taken  early  (Pre-Phase  0.  if  possible)  in  the  acquisition  cycle; 

(1)  Assignment  of  a  laboratory  Technology  Transitbn  Manager  at  the  earliest  possible 
opportunity  to  coordinate  technology  transition  activities  between  the  acquisition  project/program  and  the 
lat^atories. 

(2)  Assignment  of  a  Chief  Engineer  to  the  program.  An  important  function  of  engineering  is  to 
support  evaluation  of  laboratory  technologies  for  specific  system  applications. 

(3)  Assignment  of  dedicated  logistics  support.  An  important  function  of  logistics  is  to  support 
evaluation  of  laboratory  technologies  for  specific  system  applications. 

(4)  Identification  of  the  operating  command  Action  Officer  and  his  means  of  input  to  the 
operating  command  review  of  laboratory  programs. 

(5)  Vigorous  participation  in  the  relevant  mission  area  TPIPT  and  technology  program  generation 
within  the  laboratories.  Build  support  for  the  system,  and  thus  the  laboratory  response  to  system  needs, 
through  prartnership  with  the  labs  and  operating  command. 

8.  ENTRANCBEXIT  CRITERIA: 

a.  Entrance:  The  acquisition  cycle  initial  interface  with  the  laboratory  should  be  an  ongoing 
process  through  participation  in  the  Technical  Planning  Integrated  Product  Teams  (TPIPTs). 

b.  Exit;  Laboratory  involvement  in  an  acquisition  program  doesn't  always  end  when  identified 
technologies  have  been  developed,  demonstrated,  and  transitioned  to  the  acquisition  program. 
Laboratory  personnel  are  usually  provided  to  support  program  offices  to  assist  in  application  and  fielding 
of  new  technologies.  This  support  can  continue  for  the  entire  life  cycle  of  the  system. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  The  following  inputs  to  the  laboratory  are  the  basis  for  improving  the  effectiveness  of 
technology  development,  demonstration,  and  transition; 

(1)  From  DOS; 

(a)  Technology  Area  Assessments  conducted  by  TPIPTs  and  used  as  input  by  mission 
area  planners  (04)  and  laboratories  (D30). 

(b)  Briefings  from  TPIPTs  to  mission  area  planners  (04),  laboratories  (D30),  industry 

(D29).  etc. 

(2)  From  D09:  Evaluations  of  laboratory  advanced  technology  development,  demonstration 
and  transition. 
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(3)  FromDId;  Guidance  on  the  technology  needs  are  provided  to  appropriate  labor^ories 
(030).  The  TPIPTs  publish  an  annual  Technology  Investment  Recommendation  R^jort  (TIRR)  and  a 
Mission  Area  Development  Plan  (MADP)  that  describes  15  to  20  years  of  planned  Air  Fo^ 
developments,  including  laboratories,  SPOs/PGMs/MGMs,  arxj  operatirrg  commands. 

(4)  From  D20B;  Draft  technical  plans  for  review. 

(5)  FromD23;  Updated  technical  plans  for  review. 

(5)  From  D37;  Critical  technologies  list. 

(6)  From  037B;  Refinements  to  Advanced  Technologies  Needed  for  Transition  and 

Integration. 

(7)  FromD43: 

(a)  Technology  Investment  Recommendation  Reports 

(b)  Requests  for  Technical  Assistance 

(c)  Laboratory  Program  Assessment  Reports 

(d)  Draft  Technology  Transition  Criteria  for  the  TTP 

(8)  From  D76;  Request  for  laboratory  support  of  the  critical  technology  demonstrations  being 
planned  by  the  SPO. 

b.  The  following  outputs  from  the  laboratory  are  necessary  to  successfully  accomplish  the 
respective  acquisition  program  tasks. 


(1)  ToD05andD43: 

(a)  Technology  Program  Reviews  (WUXP) 

(b)  Technology  Plans  for  Wright  Laboratory  (WL/XPR). 

(c)  Technology  Area  Plans  (WL/XPR) 

(d)  IR&D  Annual  Program  Reviews  (WL/XPR) 

(e)  IR&D  Annual  Plans  and  Reports  (WUXPR) 

(0  Literature  Searches  (WL/DOC).  The  Wright  Laboratory  Technical  Library  would  be 
the  primary  facilitator  for  accomplishing  literature  searches.  WL-assisted  literature  searches  will  allow 
you  to  search  the  DTIC  and  other  information  databases  through  which  you  should  be  able  to  find 
information  on  technology  development  programs  of  OoD  laboratories  other  than  WL.  These  searches 
can  be  coordinated  with  the  emerging  Technology  Transition  Office  (TTO)  to  prevent  duplication  of 
effort. 
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(2)  To  DOS:  Evaluate  laboratory  advanced  technology  development,  demonstration  and 

transition 

(3)  To  D13,  D27  and  D41;  Market  surveillance  of  laboratories  and  the  industrial  base 
through  trade  shows,  trade  catalogs,  and  trade  magazines  is  the  primary  method  for  gaining  knowledge 
of  existing  technology  and  products  (D29).  These  are  a  few  of  the  methods  employed  by  the  TTO  in 
maintaining  a  database  of  available  technologies.  An  updated  cost  effective  analysis  should  be 
performed  on  the  item  in  the  associated  development  block  (D9,  D37,  D37B),  to  find  if  it  is  a  viable 
solution  to  the  item  needed. 

(4)  To  D14,  D28,  and  D42:  Cooperative  development  opportunities  should  include 
subsystems  and  technologies  as  well  as  projects  and  systems.  An  evaluation  must  be  made  of  the 
potential  for  cooperative  development  in  new  and  existing  similar  programs.  The  laboratory  (WL/XPI 
and  functional  offices)  can  support  evaluation  of  technology  and  subsystem  devetopment  efforts  being 
undertaken  by  allied  nations  relative  to  our  acquisition  program  needs. 

(5)  To  D20B:  Review  and  comments  on  the  draft  technical  plans. 

(6)  To  D23:  Review  and  comments  on  the  updated  technical  plans. 

(7)  To  D37B;  Assessments  of  Advanced  Technology  for  Transition. 

(8)  To  D64:  Review  and  comments  on  draft  RFPs. 
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(9)  ToD70;  Suppoft  source  selection  technical  evaluations. 

(10)  To  076:  Provide  support  to  the  criticai  technology  demon^rations  being  planned  by  the 

SPO. 

10.  KEY  REFERENCES: 

a.  AFMC  Pamphlet  800-60,  'Integrated  Weapon  System  Management  (IWSM),'  31  Mar  93. 

b.  'Guide  to  the  Tectmology  Master  Process,'  30  CX:t  92.  OPR:  HQ  AFMC/ST,  WPAFB,  OH. 

c.  ASC  Technology  Transition  Process  Critical  Process  Team  Final  Report,  Jun  93.  OPR: 
WUXPT,  WPAFB,  OH. 

d.  See  referenced  data  sheets. 

11.  IMPLEMENTATION  TOOLS: 

a.  Process: 

(1)  TPIPTs:  TAA  ,  TIRR,  and  MADP. 

(2)  Laboratory  Investment  Strategy:  Spring  Reviews.  Laboratory  Roadmap  Reviews, 
Laboratory  Technology  Area  Plans. 

b.  Methodology: 

(1 )  Operating  command,  product  center  XR:  MAA  and  MNA. 

(2)  Implementing/Supporting  Commands  Analysis-based  technology  needs  provide  the 
strorigest  case  for  S&T  investment.  These  analyses  begin  with  the  Mission  Area  Assessment  and 
Mission  Need  Analysis  that  implement  'strategy-to-task'  and  'task-to-need,'  respectively.  The  next  step, 
'need-to-technology,'  requires  consideration  of  acquisition  and  sustainment  needs.  Quality  Function 
Deployment  (QFD)  is  one  tool  that  provides  a  stnjctured  methodology  for  'need-to-technology'  analysis. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Activity  covers  the  entire  acquisition  cycle;  critical  phases  are; 

(1)  CE  and  D  establishes  the  techrK)logy  requirements 

(2)  Dem  Val  validates  the  technology  against  the  application  rec^irements 

(3)  EMD  integrates  the  technology  into  the  system 

b.  CONSTRAINTS:  The  greatest  obstacle  to  overcome  is  schedule,  the  lead  time  required  to 
develop  a  technology.  The  time  required  to  identify  a  specific  technology  need,  initiate  a  laboratory 
ATTD  effort,  and  transition  a  technology  can  be  prohOjitive  to  successful  insertion  into  the  program. 
Identification  of  needs  at  the  earliest  possible  time,  allowing  the  labs  to  plan  funding,  execute  advanced 
development,  and  support  the  acquisition  schedule,  is  critical  to  technology  availability. 

c.  RESOURCES:  Level-of-effort  necessary  to  manage  technology  transition  can  vary  widely 
between  programs  and  technologies.  Engineering  and  logistics  are  the  princ^le  participants.  The 
presence  of  laboratory  personnel  in  the  project  office  can  reduce  the  manpower  investment  significantly. 
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d.  LESSONS  LEARNED: 

(1)  The  rigorous  determination  and  verification  of  operating  conwnand 
needs/wants/requirements  is  necessary  to  identify  the  capabiNies  required  by  the  operating  correnand. 

(2)  Accurate  execution  of  the  strategy-to-task,  task-to-need,  and  need-to-technoiogy  analyses 
is  critical  to  identifying  the  technologies  with  maximum  leverage  on  program  cost  arxt  system  capability. 

(3)  Involvemenl  of  Systems  Engineering  at  the  earliest  opportunity  assures  buy-in  and 
validation  of  conceptual  efforts,  easing  the  transition  to  Phase  0. 

e.  BEST  PRACTICES:  Teaming  of  lab,  program.  Development  Planning  (XR  at  ASC).  Program 
Development  Team  (YX  at  ASC),  and  Operating  Command  at  the  eartiest  oppor^riity  is  the  best 
approach  to  assure  all  inputs  are  considered  and  understood  on  the  path  to  providing  the  product  that 
best  meets  the  customer  and  acquisition  program  needs. 

f.  TRAPS:  None  Identified 


i  i 


D-364 


N0¥t3 


1.  ELEMEKT:  D31.  TBS  1.1 .4.4  ( IFC  93-3) 

2.  ELEMENT  TITLE:  Update  Database 

3.  ELEMENT  OWNERS:  Operating  Command,  Implementing  Command,  Product  Center  Development 
Planning  Directorate  (XR)  and  Program  Developm^  SPO  (ASC/YX).  Industry 

4.  ELEMENT  STAKEHOLDERS: 

a.  Implementing  Agencies:  Department  of  Defense  (DOD),  Secretary  of  the  Air  Force  (SAF), 
Implementing  Command,  Product  Center  XR  and  YX  (ASC). 

b.  Supporting  Agencies:  Air  Force  Intelligence  Support  Agency  (AFISA),  Air  Force  Studies  and 
Analysis  Agency  (AFSAA),  Laboratories,  Industry,  Operating  Commands. 

5.  REQUIREMENT: 

a.  Air  Force  Policy  Directive  (AFPD)  10-6,  Mission  Needs  and  Operational  Requirements,  19 
Jan  93:  This  directive  requires  the  implementation  of  the  DOD  5000  series  documents,  which  in  turn 
requires  the  maintenance  of  database. 

b.  AFPD  37-1 ,  Information  Management:  (On  order,  upon  receiving  document,  the  definition 
will  be  constructed). 

c.  AFPD  63-1 ,  Acr^Jisition  System:  (On  order). 

d.  AFR  55-43,  Management  Operations,  Test  and  Evaluatbn,  29  Jun  90:  This  regulation 
f  describes  the  support  document  requirements  and  the  Data  Management  and  Analysis  Plan. 

e.  Department  Of  Defense  Directive  (DODD)  5000.1 ,  Defense  Acquisition,  23  Feb  91 : 
Establishes  a  disciplined  management  approach  for  acquiring  systems  and  materiei  that  satisfy  the 
operational  user's  rteeds. 

f.  DODD  8320.1 ,  Data  Administration,  26  Sept  90:  (On  order) 

g.  MIL-STD-1388-1 A,  Logistics  Support  Analysis  (LSA),  1 1  Apr  83:  The  goal  of  this  standard  is 
a  single,  uniform  approach  by  the  Military  Services  for  conducting  activities  necessary  to  cause 
supportabiKty  requirements  to  be  an  integral  part  of  system  requirements  and  design,  with  documentation 
developed  and  maintained. 

h.  MIL-STD-499B.  Systems  Engineering,  Draft:  The  decision  database  may  be  digital,  defined 
by  the  Government  or  left  open  for  contractor  definition. 

i.  MIL-STD-1388-2B.  DOD  Requirements  for  a  Logistics  Support  Analysis  Record,  28  Mar  91 : 
This  standard  is  directed  toward  improving  the  cost  effectiveness  of  the  generation,  maintenance, 
ao^isition,  and  use  of  the  technical  data  required  to  support  an  LSA  program. 

j.  MIL-STD-1840A,  Automated  Interchange  of  Technical  Information,  22  Dec  87:  The  purpose 
of  this  standard  is  to  standardize  the  digital  interface  between  organizations  or  systems  exchanging 
digital  forms  of  technical  information  necessary  for  the  logistic  support  of  weapon  systems  throughout 
their  life  cycle. 


f: 


0 


4rj 


0 


0 


0  • 


D-365 


•  *  «  *  •  *  ■  *  • 


NdvM 


6.  PURPOSE/OBJECnVES: 

a.  Purpose:  The  purpose  of  the  program  database  is  to  provide  a  central  location  for  the 
collection  and  storage  of  information  /  data.  The  information/data  will  support  the  Proiect  Team  in 
making  decisions  that  respond  to  external  and  internal  requirements.  (i.e.  the  information  needs  of 
milestone  decision  authority). 

b.  Objective:  At  this  point  the  database  is  updated  using  Phase  0  project  activities  planned 
since  the  establishment  of  the  project  database  (0-15). 

7.  DESCRIPTION: 

a.  The  database  is  the  information  used  and  generated  for  integrated  requirements  and 
flowdowns,  interface  constraints  and  configuration  altematives.  verifications,  decision  criteria,  trade  study 
assessments,  and  any  other  required  documents.  It  includes  physical  and  mathematical  models, 
computer  simulations,  layouts,  and  simUar  configuration  documentation  and  technical  data,  as 
appropriate.  To  update  the  database  at  this  time  is  important,  because  milestone  direction  has  been 
received  by  the  project  team  and  incorporated  in  Phase  0  program  plans  (D22)  and  Phase  0  technical 
plans  (D23). 

b.  An  operational  database  will  continue  to  use  MiL-STD-1388,  MIL-STD-4996,  MIL-STD- 
1840A,  Computer-Aided  Acquisition  and  Logistics  Si4)port  (CALS),  Contractor  Integrated  Technical 
Information  Service  (CITIS),  and  Integrated  Weapon  System  Management  (IWSM).  The  management 
information  system  will  continue  to  provide  tools  for  engineers;  share  program  data  with  analysts, 
contractors,  and  the  customer;  permit  management  overview  of  program  data  and  schedules;  and 
provide  paperless  delivery,  if  appropriate,  of  required  data.  To  conduct  Concept  Exploration  Studies 
(037),  the  database  must  contain  approved  Work  Statemer^s.  the  Preliminary  Cost  and  Operatbnal 
Effectiveness  Analysis  (COEA)  plan,  top  level  systems  requirements,  approved  alternative  corx^pts  and 
operational  requirements,  as  w^  as  plans  and  schedules  to  conduct  systems  engineering  activities. 
Preliminary  design  (for  the  Synthesis),  and  performance  and  alternative  design  concepts  (for  Balance 
ard  Control )  require  complete  data. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  EntrarKe:  This  is  a  continuous  activity,  intended  to  be  current  since  established  in  01 5. 

b.  Exit:  The  data  base  will  continually  be  updated  throughout  the  Pre-Milestone  1  process  and 

beyond. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  From  Updated  Technical  Plans  (023): 

(1)  Updated  Work  Statements 

(2)  Preliminary  COEA  Plans 

(3)  Preliminary  Systems  Requirement  Oocument  (SRO) 

(4)  Oraft  Baseline  Concept  Oescription  ( BCO) 

From  Updated  Phase  0  Plans  (022): 

(1)  IWSM  Master  Plan 

(2)  Acquisition  Strategy 

Other  approved  pertinent  information  since  Establish  Oatabase  (015) 
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b.  Outputs: 

(1 )  All  above  inputs  are  used  unaltered  as  outputs 

(2)  Data  to  conduct  Concept  Exploration  Studies  (D37) 

(a)  Work  Statements 

(b)  Preliminary  COEA  Plan 

(c)  Other  approved  pertinent  intormation  for  successor  block  activities 
10.  KEY  REFERENCES:  (In  addition  to  those  listed  in  Requirements,  Paragraph  5) 

a.  Air  Force  lnstnx:tion  (AFI)  10-601 ,  Mission  Needs  and  Operational  Requirements  Gkjidance 
and  Procedures,  16  Feb  93;  Identifi^  official  Air  Force  information  required  for  decision  making  and 
historical  purpose  and  develop  a  schedule  of  the  information  life  cycle  to  describe  creation, 
maintenance,  and  disposition  (AFI  37-123,  Management  of  Records). 

b.  AF1 10-602,  Logistics  Support  and  Readirtess  Requirements;  (On  order,  upon  receiving 
documertt,  the  definition  will  be  written.) 

c.  AF1 14-303,  Threat  Support,  Acquisition  Process:  (On  order). 

d.  AF1 16-501,  Control  and  Documentation,  Air  Force  Programs;  (On  order). 

e.  AFI  33-105,  Information  System,  Standard  Programs;  (On  order). 

f.  AFI  37-1,  Information  Management;  (On  order). 

g.  AFI  37-1 23,  Management  of  Records:  Identifies  the  activities  to  plan,  design,  irxxlel, 
synchronize,  standardize  and  control  Air  Force  Corporate  data  at  all  echelons. 

h.  AFI  37-150,  Data  Administration  and  Standards  Program:  (On  order). 

i.  DOD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 :  Establishes  an  integrated  framework  for  translating  broadly  stated  mission  needs  into  stable, 
affordable  acquisition  programs  that  meet  the  operational  user's  needs  and  can  be  sustained,  given 
projected  resource  constraints. 

j.  DOD  Manual  5000.2M,  Defense  Acquisition  Management  Documentation  and  Reports,  23  Feb 
91 ;  This  Manual  implements  relevant  portions  of  DODD  5000.1  and  DODD  5000.2.  Specific 
responsibilities  pertaining  to  major  areas  are  provided  in  each  irxlividual  section,  as  appropriate. 

k.  Implementing  Command:  Submit  required  acquisition  program  documents.  (Defense 
Planning  Guide,  Mission  Area  Assessment,  and  Mission  Needs  Analysis,  etc.). 

l.  MIL-HDBK-59A,  DOD  Computer-Aided  Acquisition  and  Logistic  Support  (CALS)  Program 
Implementation  Guide:  The  purpose  of  this  military  handbook  is  to  provide  general  information  and 
detailed  application  guidance  for  contractually  implementing  CALS  requirements  in  weapon  system  and 
related  major  equipment  procurements. 

m.  MIL-HDBK-X499-3,  Systems  Engineering/Configuration  Management.  Draft:  The  decision 
database  will  provide  an  audit  trail  from  initially  stated  needs  and  requirements  to  the  current  description 
of  system  products  and  processes. 
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n.  Secretary  of  the  Air  Force  (SAF/AAI):  SAF/AAI  win  ensure  compliance  with  DOD  Corporate 
Information  Management  (CIM)  to  allow  sharing  of  data  w^h  s^opriate  DOD  agencies  and  other 
Government  agencies. 

o.  Supporting  Command:  The  Supporting  Command  win  collect  and  process  Inte^ated  Logistic 
Support  (ILS)  information  in  the  Logistics  Management  Information  System  (LMIS).  Outline  the  actions, 
support,  and  documentation  needed  to  establish  maintenance  requirements  for  on  and  off  ec^ipment 
throughout  the  life  of  the  system.  Identify  data  collection  and  analysis  efforts  that  will  continue  after 
fielding  of  system  equipment. 

p.  Usir)g  /Operating  Command;  The  user  will  ensure  data  and  management  needs  are 
identified.  Integrate  the  Logistics  Support  Analysis  process  with  the  System  Requirements  Analysis 
activity.  Outline  the  actions,  support,  and  documentation  needed  to  establish  maintenance  requirements 
for  on  and  off  equipment  throughout  the  life  of  the  system. 

11.  IMPLEMENTATION  TOOLS: 

a.  Automated  Data  Processing  (ADP)  is  available  as  Government  Furnished  Property  (GFP). 

Contact: 

Director  USAMC  Logistic  Support  Activity 
ATTN.:  AMXLC-AL 
Lexington,  KY  40511-5101 
606-293-4193  (Mr.  David  Henderson) 

b.  Computer-Aided  Acquisition  and  Logistic  Support  (CALS);  The  repository  of  information  used 
and  generats<f  at  the  appropriate  level  for  the  acquisition  phase  of  integrated  requirements  and 
flowdowns:  interface  constraints  and  requirements:  functional  and  performance  requirements;  system 
concept;  preliminary  design  and  configuration  alternatives;  details  design;  verifications;  decision  criteria; 
trade  study  assessments;  system,  subsystem,  and  functional  capability  assessments;  and  other  required 
documentation. 


(a)  MIL-HDBK-59A 

(b)  MIL-STD-1840A 

c.  Systems  and  Logistics  Integration  Capability  (SLIC):  This  is  a  state-of-the-art,  DOD  Type  III 
validated,  microcomputer  based  LSAR  system  that  can  be  used  to  completely  satisfy  all  MIL-STD-1388- 
2A  requirements  with  total  independence  from  any  other  hardware  and  software. 

(a)  SLIC  I 

(b)  SUCH 

12.  PLANNING  GUIDANCE: 

a.  DURATION;  Update  the  database  continuously,  throughout  the  entire  life  of  the  product. 

b.  CONSTRAINTS: 

(1)  Identify  computer  resource  constraints  (examples  include  language,  computer,  data 
base,  architecture,  or  inter-operability  constraints). 

(2)  Database  capacity  (identify  spare  memory  and  throughput  requirements,  computer 
merrxsry  growth  requiremerrts,  software  partitioning  and  modular  design  requirements  such  as  software 
module  size  (e.g.,  no  greater  than  100  lines  of  code). 

(2)  Access  capabilities 
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(3)  Secur^  restrictions 

(4)  Time 

(5)  Assumptions 

(6)  Funds 

(7)  Management  Resources 

(8)  Training 

c.  RESOURCES: 

(1)  Facilities 

(a)  Classified  work  space 

(b)  Personnel  office  space  and  supplies 

(c)  Database  location 

(2)  Coniputer  hardware  and  software  programs 

(a)  Artalytical  rmdels 

(b)  Program  Management  Software 

(3)  Security 

(a)  Type  of  access  required 

(b)  Provide  access  for  contractors 

(4)  Manpower 

(a)  Security  personnel 

(b)  Computer  systems  personnel 

(c)  Data  mana'^ement  personnel 

d.  LESSONS  LEARNED:  (First  two  lessons  transcribed  from  ALLCARS,  the  others  are 
referenced). 

9  (1)  #  1982,  Program  Directors:  Enhanced  quality  and  quantity  of  information  on  the 

AFAM  database.  Improvements  include  additional  lessons  learnt  and  best  practices,  updated 
references,  increased  number  of  tools  such  as  software  programs,  document  templates,  samples,  and 
courses.  (Col.  Ferrell,  ASC/CYM.  DSN  785-2213) 

(2)  #1344,  Schedule  Plan  For  A  Source  Selection;  Develop  a  detailed  plan  tor  the 
execution  of  source  selection  that  will  aid  the  flow  of  data  and  provide  exp^ient  changes  to 
contingencies.  All  data  was  computerized  on  an  IBM  program  called  "Super  Project."  The  data  were 
placed  in  a  network  to  define  the  internal  relationships  of  activities  and  resources  and  a  Gantt  chart  was 
used  to  provide  schedule  suspense  dates  and  serve  as  a  tracking  tool.  By  computerizing  the  database 
"what-iT  scenarios  could  be  evahjated  based  on  unknown  contingencies  (i.e.,  slip  of  data  reviews, 
modifications  to  the  proposals,  personnel  conflicts  or  absences).  The  database  was  used  as  a  "living 
tooT  to  help  manage  200  evaluators,  18  evaluation  items,  and  7  proposals.  (POC  will  be  added  at  later 
date). 

(3)  #  1264,  AFLC  LMS  Target  Operating  Environment 

(4)  #1418,  Internal  Financial  Management. 

(5)  #1888,  Program  Managers: 

(6)  #  1982,  Program  Directors 

(7)  #  9020,  Hardness  Surveillance  Test  Systeme  (PHSTS) 

(8)  #  9063,  Air  Force  Electronic  Combat  Office  (AFECO  ) 

(9)  #9115,ASIAC 

(10)  #9116,  Reliability  Analysis  Center  (RAC) 

e.  BEST  PRACTICES:  Use  MIL-HDBK-59A,  DOD  CALS  Program  Implementation  Guide,  and  MIL- 
STD-1840A,  Automated  Interchange  of  Technical  Information  to  control  data  storage  with  frequent 
backups  to  avoid  the  loss  of  data. 
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f.  TRAPS:  Noricompatibie  CALS  systems  have  problems  with  nonstandard  terminology  used  to  file 
or  retrieve  data. 
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1.  ELEMENT:  D34.  TBS  1.1. 1.4  (IFC  93-3) 

2.  ELEMENT  TITLE:  Develop  Phase  0  Contracted  Studies  Strategy 

3.  ELEMENT  OWNER(S):  Product  Center  PK 
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4.  ELEMENT  STAKEHOLDER(S):  Project  Manager  (PM),  Project  Contracting  Office.  Legal  Office, 
Program  Executive  Officer  (PEO)  (if  identified).  Designated  Acquisition  Commander  (DAC),  ASC/CYX, 
SAF/AQC/AQ,  AFMC/PK,  USAF/XO,  Operating  Command,  and  Project  Cadre  (comprised  of  functional 
disciplines,  e.g.,  EN,  FM,  PK,  XR,  LG.  Labs,  etc.). 

5.  REQUIREMENT: 

a.  AFR  70-14,  Acquisition  Strategy  Panels  (ASPs),  Aug  92,  provides  general  ot^ectives  and 
policies  for  ASPs  and  establishes  responsibilities  under  the  PEO  and  DAC  stmcture. 

b.  AFMC  FAR  Sup  5307.1  and  AFMCR  800-25,  31  May  89,  contain  the  requirements  for  when 
and  how  to  conduct  an  ASt . 

c.  FAR  7.1,  DFARS  207.3,  AFFARS  5307.1,  AFWC  FAR  Sup  5307.1  and  ASC  FAR  Sup  5307.1 
all  contain  requirements  on  when  and  how  to  prepare  an  Acquisition  Plan  (AP) 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  activity  is  to  ensure  there  is  a  contract  strategy  -  a  plan  -  for 
executing  any  required  Phase  0  contracts.  This  follows  the  determination  by  the  PM  and  the  operating 
command  that  concept  exploration  and  definition  studies  will  be  conducted  by  a  contractor(s)  (D35).  This 
contracting  strategy  will  also  be  used  in  support  of  the  overall  acquisition  strategy  develop^  for  Phase  0. 

b.  Objectives:  The  objective  is  to  develop  a  draft  contracting  strategy  that  fulfills  the  needs  of 
the  project  by  considering  risk,  contract  method,  period  of  performance,  etc.  It  is  also  needed  to 
determine  what  type  of  contract  vehicle  will  be  used  for  those  studies  and  what  will  be  required  in  the 
resultant  contract. 

7.  DESCRIPTION: 


a.  During  this  phase  of  the  project,  the  PM  and  the  project  cadre  are  supporting  the  operating 
command  by  planning  for  Phase  0  (D20a  and  D20b).  This  contracting  studies  strategy  will  be  a  part  of 
the  overall  project  planning.  The  strategy  will  be  used  if  it  is  decided  to  have  industry  conduct  concept 
exploration  and  definition  studies  during  Phase  0  that  will  help  lead  to  a  Milestone  I  approval.  This 
planning  and  strategy  may  be  addressed  during  the  briefings  leading  to  the  Milestone  0  decision  and  will 
be  updated  as  required. 

b.  Once  the  project  cadre  has  determined  the  need  to  contract  with  one  or  more  contractors  who 
have  technical  knowledge  and  capability  of  the  project,  the  next  step  is  to  develop  a  contracting  strategy. 
Approval  of  that  strategy  is  obtained  by  preparing  for  and  conducting  an  ASP,  if  required  or  desired. 

(The  tailorable  Integrate  Acquisition  Strategy  Process  (lASP)  with  its  roundtables  might  also  be 
considered  to  help  formulate  the  strategy.)  One  major  factor  involved  in  preparing  the  strategy  and 
obtaining  approval  is  the  acquisition  dollar  value  for  this  effort.  The  value  of  the  project  determines  the 
level  of  strategy  approval,  and  how  many  contracts  can  be  awarded  for  contractors  to  perform  the 
studies.  An  ASP  is  conducted  for  each  AFMC  program  that  requires  an  AP,  except  for  Budget  Program 
Activity  Codes  (BPACs)  6.1  and  6.2-funded  programs  that  are  not  applicable  to  this  activity.  (The 
acquisition  dollar  level  and  type  of  program  [i.e.,  major/selected  programs,  other  programs  or  other 
contracting]  will  determine  if  an  AP  is  required.  See  the  above  FAR  references  for  AP  requirements  and 
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approval  levels.)  The  ASP  is  a  forum  of  senior  acquisition  personnel.  The  purpose  of  an  ASP  is  to  help 
the  PM  formulate  an  effective  acquisition  strategy.  The  PM.  with  help  from  project  office  functionals,  the 
project  cadre,  is  responsible  for  formulating  the  strategy,  briefing  the  strategy  at  the  ASP  and  addressing 
the  recommendations  of  the  ASP.  The  contract  strategy  is  only  one  aspect  briefed  during  the  ASP  which 
performs  a  total  integrated  strategy  assessment  (technical,  programmatic,  financial,  support  and 
business).  Subsequent  to  the  ASP,  an  AP  will  be  required,  depending  upon  the  dollar  level  of  the 
acquisition(s)  and  the  type  of  funds  available.  Two  major  aspects  of  the  contracting  strategy  are  to 
determine  what  type  of  contract  vehicle  win  be  used  and  whether  the  action  will  be  competrtive  or 
noncompetitive.  Oeperfoing  on  many  project  factors,  the  strategy  may  be  to  issue  a  new  contractual 
vehicle  or  use  an  existing  one.  (i.e.,  task  order).  (An  ASP  or  AP  is  not  needed  if  a  task  is  being  added  to 
an  existing  contract.)  For  a  new  contract,  different  solicitation  types  should  be  studied.  Requests  for 
Information  (RFI),  Requests  for  Proposals  (RFP),  Program  Research  and  Development  Announcements 
(PRDAs),  affo  Broad  Area  Announcements  (BAAs)  are  examples  of  types  that  should  be  explored  for 
use.  Th^e  will  be  discussed  further  in  the  data  sheet  for  D35.  Once  the  ASP  has  approved  the 
contracting  strategy,  the  AP  can  be  finalized  and  started  on  its  approval  cycle  and  a  solicitation  can  be 
initiated. 

c.  This  initial  strategy  will  be  updated  after  the  MS  0  decisbn  (D22). 

8.  ENTRANCeEXIT  CRITERIA: 

a.  Entrance;  This  activity  can  begin  when  the  operating  command  determines  they  have  an 
operational  need  not  satisfied  by  non-materiel  solution  (C14).  The  PM  then  initiates  the  pr(^uct  center’s 
support  of  the  operating  command  in  their  planning  for  how  Phase  0  will  be  conducted  (D20a  and  20b). 
This  is  the  time  when  the  contracting  strategy  effort  is  initiated  to  support  the  Phase  0  planning. 

b.  Exit;  This  effort  ends  when  the  initial  contracting  strategy  to  support  Phase  0  has  been 
approved  and  becomes  a  part  of  the  overall  initial  Phase  0  planning  to  support  the  operating  command. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a  Inputs;  The  main  input  needed  for  this  effort  is  the  determination  as  to  the  extent  to  which 
Industry  will  be  involved  and  how  they  will  be  reimbursed  for  their  efforts.  Phase  0  strategy  technical 
alternatives  needed  to  develop  the  contracting  strategy  will  come  as  a  result  of  the  Phase  0  planning 
effort  being  conducted  by  the  PM  and  project  team  (D20a).  Other  technical  input  required  to  develop  the 
strategy  will  be  derived  from  the  development  of  the  draft  Phase  0  technical  plans  (D20b).  The  Industry 
technical  analysis  requirements  from  D20b  depend  on  available  technical  resources  and  capability  in- 
house. 

b.  Outputs;  The  output  is  the  initial  contracting  strategy  inat  will  include  plans  for  managing  the 
contractor-conducted  concept  exploration  and  devinilion  studies  and  also  what  type  of  solicitation  and 
contract  will  be  used  to  obtain  this  effort.  This  strategy  will  be  incorporated  in  the  overall  initial  Phase  0 
strategy  for  obtaining  a  Milestone  0  decision  (D20a  and  Cl 4), 

10.  KEY  REFERENCES:.  DOD  Instaiction  5000.2,  Defense  Acquisition  Management  Policies  arxJ 
Procedures,  23  Feb  91 ,  Part  5,  Section  A  provides  information  on  acquisition  plannirig  and  strategy. 
Change  1  to  DODI  5000.2  is  dated  10  Mar  93. 

1 1 .  IMPLEMENTATION  TOOLS: 

a.  ASC/CYX  "A  Schedule  for  Acquisition  Planning";  Initial  Acquisition  and  Strategy 
Development  Through  Source  Selection."  contains  guidance  on  acquisition  planning  and  ASPs. 
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b.  HQ  AFSC  Request  for  Proposal  Process  Guide.  This  document  contains  sections  which 
include  information  on  ASPs. 

c.  ASC/CYX  has  guidance  for  conducting  ASPs.  Contact  them  at  DSN  785-7073. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  This  entire  contracting  strategy  process  from  the  time  it  is  decided  to  obtain 
contractor  conducted  concept  exploration  and  def^ion  studies  until  the  strategy  is  approved  could  take 
anywhere  from  one  month  to  more  than  6  months,  deperxiing  on  the  complexity  and  dollar  amount  of  the 
project.  For  lower  dollar  and  visibility  programs,  it  can  take  anywhere  from  1  to  3  months  from  the  tkne 
the  contracting  strategy  is  initiated.  For  potential  Defense  Acquisition  Board  (DAB)  programs,  it  can  take 
more  than  6  rrxjnths  arid  possibly  even  a  year. 

b.  CONSTRAINTS: 

(1 )  A  decision  needs  to  be  made  whether  it  is  necessary  or  advantageous  to  obtain 
contractor  conducted  concept  exploration  and  definition  studies  (D20a).  If  the  corrtractor  studies  will  not 
be  obtained,  there  is  no  need  for  a  contracting  strategy. 

(2)  The  ASP  needs  to  be  planned  around  when  the  approval  authority  will  be  available 
to  hear  the  ASP  briefing  and  make  a  decision  on  the  strategy.  Also,  included  in  this  is  the  difficulty  in 
scheduling  the  ASP  members. 

c.  RESOURCES:  Personrtel  resources  include  personnel  in  the  project  cadre,  plus  clerical 
assistance,  to  help  plan  the  contracting  strategy  and  prepare  for  the  ASP.  In  addition,  personnel  who  are 
members  of  the  ASP  will  be  required  when  the  briefing  e  presented  to  that  panel.  The  ASP  is  usually 
made  up  of  senior  functional  personnel  (greybeards),  including  the  legal  office,  the  using  activity  and 
various  other  personnel. 

d.  LESSONS  LEARNED:  ASC/CYX  (DSN  785-7073)  provides  regular  updates  of  significant 
lessons  learned  resulting  from  completed  ASPs.  It  is  advisable  that  you  talk  with  them  prior  to  initiating 
actions  for  your  ASP. 

e.  BEST  PRACTICES: 

(1)  The  ASP  is  an  important  element  of  successful  acquisition  planning  which  should  be 
an  iterative  process  led  by  the  Project  Manager.  It  involves  teamwork  by  the  functional  offices,  project 
office,  Operating  Command,  field  activities.  Headquarters,  DAC  and  PEO  (if  applicable),  as  required. 

(2)  Prebriefings  of  the  briefing  prepared  for  the  ASP  should  be  conducted  whenever 

feasible. 

(3)  HQ  AFMC  and  field  activities  are  responsible  for  establishing  an  ongoing  activity 
called  the  ASP  secretariat.  This  secretariat  (ASC/CYX,  at  ASC)  helps  the  chairperson  oversee  and 
monitor  all  ASP  activities  and  provides  scheduling  support  and  meeting  minutes  as  described  in  AFMCR 
800-25. 


(4)  It  is  important  that  the  ASP  be  scheduled  early  in  the  acquisition  planning  process. 
The  ASP  should  occur  when  the  contracting  strategy  is  organized. 
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f.  TRAPS: 

(1)  One  tra«>  is  not  scheduling  the  ASP  eaily  enough  in  the  project  acquisition.  It  can 
take  a  long  time  to  schedule  an  ASP  when  al  the  members  can  attend,  and  could  delay  the  project  if  not 
held  in  a  timely  manner.  It  is  suggested  that  the  ASP  be  held  prior  to  the  Air  Force  Systems  Acquisition 
Review  Council  (AFSARC)  (89)  or  Milestone  Review  (A9). 

(2)  Depending  on  the  situation,  there  may  be  some  problems  using  existing  task  orders 
for  this  effort.  This  may  not  allow  adequate  compeliticn  (which  might  be  illegal  under  the  Ckxnpetition  in 
Contracting  Act  (CICA))  and  could  keep  the  proj^  from  receiving  beneficial  technical  information  from 
other  competing  offerors.  The  PM  and  contracts  representative  should  work  closely  with  the  Small 
Business  and  Ck>mpetition  Advocate  offices  to  ensure  all  acceptable  industry  resources  are  utilized. 
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1.  ELEMENT:  035.  TBS  1. 2.1.1  (IFC  93-3) 

2.  ELEMENT  TITLE:  Procure  Contract  Studies 

3.  ELEMENT  OWNER(S):  ASC/PKC,  ASC/CYX.  Project  Manager  and  Project  Team  Members 

4.  ELEMENT  STAKEHOLOER(S):  Project  Director,  Project  Management  Office,  Project  Contracting 
Office,  Legal  Office,  Program  Executive  Officer  (PEO)  (if  identified),  and  ASC/CYX. 

5.  REQUIREMENT: 

a.  DODI  5000.2,  Part  10.  Section  B,  provides  information  for  selection  of  contractual  sources 
and  Section  C  provides  information  on  acquisition  streamlining. 

b.  AF  Sup.  1/DODI  5000.2,  Part  10B.  supplemer^s  information  on  selection  of  contractual 
sources. 

c.  FAR  5.1 ,  DFARS  205,  AFFARS  5305,  AFMC  FAR  Sup  5305  and  ASC  FAR  Sup  5305  contain 
the  requirements  for  disseminating  information  (publicizing  contract  actions). 

d.  FAR  9.1 ,  DFARS  209,  AFFARS  5309,  AFMC  FAR  Sup  5309  and  ASC  FAR  Sup  5309 
describe  policies  for  determining  whether  prospective  contractors  are  responsible. 

e.  FAR  15.1,  DFARS  215,  AFFARS  5315,  AFMC  FAR  Sup  5315  and  ASC  FAR  Sup  5315 
describe  methods  of  contracting  by  negotiations. 

f.  FAR  16.1 .  DFARS  216,  AFFARS  5316,  AFMC  FAR  Sup  5316  and  ASC  FAR  Sup  5316 
describe  types  of  contracts. 

g.  AFR  70-15  and  70-30  contain  the  requirements  for  source  selection  procedures. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose  This  Phase  0  contractual  activity  is  required  when  the  project  director/manager 
determines  a  contractor-performed  System  Requirements  Analysis  (SRA)  (D37)  is  required  to  aid  the 
project. 


b.  Objectives:  The  objective  is  to  provide  the  contractual  vehicle,  as  directed  by  the  contracting 
strategy  (D34)  artd  as  reviewed  and  updated  (D22).  with  which  the  contractor(s)  may  deliver  SRA 
information. 

7.  DESCRIPTION:  There  are  two  methods  which  may  be  utilized  to  provide  the  necessary  contractual 
vehicle.  The  first  is  to  create  a  specific  contractual  vehicle(s)  for  the  requirement  at  hand,  using  the 
competitive  RFP  method.  This  is  to  be  used  when  no  existing  contractual  vehicle  fits  the  identified 
requirement.  The  second  method  is  to  use  an  existing  contractual  vehicle  by  modifying  the  statement  of 
work  (SOW)  or  contracting  for  an  additional  task.  The  decision  for  which  method  to  use  should  be  a  part 
of  the  contracting  strategy  (D34). 

Caution:  The  contract  strategy  was  developed  for  Milestone  0  decision,  which  may  have  been 
several  rmrtths  prior  to  this  point  in  Phase  0.  This  strategy  should  have  been  revisited  and  reviewed 
prior  to  proceeding  with  this  activity  (D22). 

Competitive  RFP:  This  Phase  0  activity  can  be  divided  into  the  following  units:  a)  source  selection  plan 
(SSP),  b)  draft  request  for  proposal  (DRFP),  c)  request  for  proposal  (RFP),  and  d)  source  selection. 
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(a)  SSP  •  An  SSP  is  required  for  all  competitive  accHiisitions  conducted  under  APR  70-15  or  70- 
30.  It  dc^ments  the  source  selection  strategy:  it  is  the  blueprint  for  conducting  the  source  selection;  it  is 
the  approved  plan  for  conducting  the  evaluation  and  analysis  of  proposals.  The  Project/Program 

Manager  (PM)  is  responsible  for  the  SSP.  The  SSP  is  submitted  to  the  source  selection  authority  (SSA)  i 

for  review  and  approval.  It  is  a  key  document  that  specifies  how  the  source  selection  wiH  be  conducted. 

The  SSP  consists  of  two  parts.  Part  one  describes  the  organization,  membership  and  responsibilities  of 
the  team.  Part  two  identifies  the  evaluation  criteria  aixf  detailed  procedures  for  proposal  evaluation. 

Schedule  -  The  SSP  should  be  written  after  the  acquisition  strategy  panel  (ASP)  is  held  and 
should  reflect  the  decisions  of  the  ASP.  The  SSP  is  prepared  at  the  same  time  that  the  contracting  p 

strategy  plan  is  being  written.  The  draft  SSP  should  be  confuted  before  DRFP  release  and  the  SSP 
must  be  approved  before  the  RFP  is  released. 

(b)  DRFP  -  The  DRFP  is  a  toe!  used  in  competitive  acquisitions  to  obtain  industry  feedback  on 
the  plann^  acquisition.  DRFPs  are  mandatory  for  all  competitive  contracts  exceeding  $25  million  and 

encouraged  for  use  for  all  other  procurements.  The  goal  of  the  DRFP  is  to  produce  a  more  effective  ^ 

RFP  and  a  better  contract  by  allowing  industry  time  to  comment  on  the  RFP  before  it  is  finalized.  The 
DRFP  should  reduce  proposal  preparation  time  and  evaluation  time  by  promoting  a  clearer 
understanding  by  the  bidders  of  the  requirements.  The  sections  of  the  DRFP  are  as  follows; 

Section  Title 

A  Contract  Form  * 

B  Supplies/Sen/ices  and  Prices 

C  Descriptions/Specifications/Statement  of  Work  (SOW) 

D  Packaging  and  Marking  Requirements 

E  Inspection  and  Acceptance  Requirements 

F  Deliveries  or  Performance 

G  Contract  Administration  Data  • 

H  Special  Provisions 

I  General  Provisions 

J  List  of  Documents,  Exhibits,  and  Attachments 

K  Representations,  Certifications,  and  Other  Statements  of  Offeror 
L  Instructions/Conditions,  and  Notices  to  Offeror 

M  Evaluation  Factors  For  Award  • 

All  of  these  sections  are  explained  in  greater  detail  in  the  AFSC  RFP  Process  Guide. 

Schedule  -  Preparation  of  the  DRFP  should  begin  with  the  decision  of  the  ASP  and  will  be  done 
concurrently  with  the  writing  of  the  SSP.  The  DRFP  should  not  be  released  until  the  SSP  is  in  draft  form. 

A  period  of  30  days  should  be  allowed  for  comments  before  the  RFP  is  revised.  All  comments  are  p 

formally  address^  by  the  Procuring  Contracting  Officer  (PCO)  either  by  letter  or  in  a  bidders 
conference.  Any  major  changes  to  the  DRFP  may  require  a  second  DRFP. 

(c)  RFP  -  The  RFP  is  Ibfi  document  that  communicates  the  government’s  requirements  to 
industry.  The  RFP  should  look  very  much  like  the  DRFP  released  earlier  for  industry  comment.  The 

release  of  the  RFP  is  authorized  by  the  SSA  which  usually  preceded  by  JAG  and  other  internal  ASC  _ 

reviews.  For  major  programs,  a  defense  acquisition  executive  (DAE)  review  may  be  required.  All  major 
programs  are  required  to  not^  the  SAF/AQC  and  DAE  no  less  than  30  days  before  a  RFP  is  released. 

The  RFP  should  clearly  highlight  those  changes  that  occurred  since  the  DRFP  was  issued.  Offerors 
frequently  prepare  their  proposals  from  the  DRFP  and  use  the  RFP  for  a  quick  last  review  before  seeking 
corporate  approval  of  their  proposal. 

Schedule  -  The  RFP  release  starts  the  formal  source  selection.  • 
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(d)  Source  Selection  -  A  source  selection  is  a  method  to  choose  from  a  number  of  qualified 
sources  available.  The  objective  of  the  source  selection  is  to  select  the  source  whose  proposal  has  the 
highest  degree  of  credibility  and  whose  performance  can  be  expected  to  best  meet  the  government's 
requirements  within  reasonable  cost.  S^rce  selection  execution  at  ASC  is  managed  by  ASC/CYX.  This 
organization  provides  training,  facilities,  and  guidance  for  source  selection  beginning  with  acquisition 
strategy  through  contract  award.  The  SSA  is  the  official  designated  to  direct  the  source  selection 
process  and  make  the  final  source  selection  decision  Who  the  SSA  is,  is  determined  by  the  size  of  the 
program.  The  ASC  supplements  to  APR  70-1 5  and  70-30  should  be  reviewed  for  the  latest  guidance  on 
how  to  determine  a  programs  size.  A  description  of  the  typical  source  selection  organization  is  available 
from  ASC/CYX.  The  source  selection  organization  supports  the  SSA  and  actually  performs  the 
evaluations  of  offerors  proposals.  It  is  usually  streamlined  for  smaller  programs. 

Schedule  -  ASC  policy  is  to  complete  all  competitively  negotiated  acquisitions  in  both  an 
effective  and  efficient  manner.  A  schedule  goal  of  120  days  from  issue  of  the  RFP  to  the  SSA  decision 
is  part  of  this  policy.  Schedule  within  this  120  days  can  be  modified  as  appropriate. 

The  majority  of  the  acquisitions  which  will  happen  at  this  point  in  Phase  0  will  be  less-than-major  actions. 
Generally,  smaller  dollar  contracting  actions  must  follow  the  same  process  as  large  ones  but  with  fewer 
and  lower  level  oversight  review  groups.  There  will  be  no  requirement  to  ncxify  the  DAE  30  days  prior  to 
RFP  release.  Also,  the  contract  reviews  will  be  done  locally  and  the  need  for  a  DRFP  is  usually  waived. 
Small  dollar  source  selections  fall  under  AFR  70-30  rather  that  70-1 5;  the  organization  structure  is 
streamlined  (smaller),  arxf  the  SSA  will  likely  be  from  the  organization.  The  overall  result  is  a  shorter 
schedule.  Typical  study  contracts  of  less  than  $2.0M  from  ASP  approval  to  contract  award  could  take  as 
little  as  90  days.  As  the  value  of  the  end  contract(s)  increases,  so  too  does  the  time  necessary  to 
complete  the  acquisition. 

Existing  Contractual  't/ehicle:  If  it  has  been  decided  during  the  contract  strategy  process  (D34  and  D22) 
that  an  existing  contractual  vehicle  can  meet  the  identified  requirement,  the  above  RFP  process  is  rK>t 
required.  To  use  the  existing  contractual  vehicle,  the  owner  of  that  document  must  be  contacted,  and 
local  policies  and  procedures  must  be  followed  to  place  the  Phase  0  requirement  on  contract.  As  a 
minimum,  a  complete  PR  package  (including  the  SOW  modification  or  task  order  description)  must  be 
provided  to  the  owner  of  the  contractual  vehicle.  Typical  contract  types  which  would  be  available  at  this 
point  in  Phase  0  include  time  and  material,  labor  fvMrs,  and  cost  reimbursement.  It  is  unlikely  that  fixed 
price  contracts  would  be  used  due  to  the  lack  of  defined  requirements  this  early  in  Phase  0. 

(a)  Time  and  Material:  These  contracts  are  used  when  it  is  not  possible  initially  to  estimate  the 
extent  or  ckiration  of  work,  e  g.  engineering  and  design  services. 

(b)  Labor  Hour.  Variant  of  time  and  material  contracts  in  that  materials  are  not  furnished  by  the 
contractor. 

The  above  two  types  of  contracts  are  not  commonly  used  in  research  and  development  efforts  and  care 
should  be  taken  to  ensure  that  if  used,  the  identified  Phase  0  effort  is  within  the  scope  of  the  existing 
contract. 


(c)  Cost  Reimbursment:  This  family  of  contract  types  permits  contracting  for  efforts  that  might 
otherwise  presertf  too  great  a  risk  to  contractors.  These  centrals  are  suitable  for  use  when  uixertainties 
involved  in  contract  performance  do  not  permit  costs  to  be  estimated  with  sufficient  accuracy  to  use  any 
type  of  fixed-price  contract.  Common  uses  include  the  performance  of  research  or  preliminary 
exploration  or  study  and  the  level  of  effort  required  is  unknown. 

Cost  reimbursement  contracts  include: 

(1)  Cost:  Research  and  development  with  nonprofit  organizations  or  educational 
institutions.  The  contractor  is  reimbursed  for  all  allowable  costs. 
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(2)  Co6t  Share:  Devetopment  or  research  projects  jointiy  sponsored  by  Government 
and  contractor  wh^  the  cortractor  anticipates  corrvnercial  benefit  in  Neu  of  fee  under  the  contract. 

(3)  Cost  Plus  Award  Fee  (CPAF):  An  award  fee  is  earned  based  upon  a  judgemental 
evaluation  by  the  Government,  sufficient  to  provide  motivation  for  excellence  in  contract  performance. 
Contract  completion  is  desired  but  performance  is  not  susceptible  to  finite  measurement. 

(4)  Cost  Plus  Incentive  Fee  (CPIF):  This  contract  provides  for  an  initiaHy  negotiated  fee 
to  be  adjusted  later  by  a  formula  based  on  the  relationship  of  total  allowable  costs  to  total  target  costs. 
These  corttracts  are  appropriate  for  development  and  test  programs  where  the  Government  has 
established  its  performance  objectives. 

(5)  Cost  Plus  Rxed  Fee  (CPFF):  This  type  of  contract  is  most  comrrK>nly  used  in 
research  and  development  where  the  level  of  effon  is  not  known  and  the  contractor's  performance 
cannot  be  subjectively  evaluated.  The  contractor  receives  a  fixed  fee  regardless  of  the  actual  costs 
incurred  during  performance. 

(6) Task  Order";  Task  ordering  arrangements  are  CPFF  term-type  contracts.  Thelevel- 
of-effort  must  be  sjsecified  in  person-hours,  and  a  fixed  fee  must  be  negotiated  on  the  basic  contract. 
Task  ordering  arrangements  are  appropriate  for  those  instances  in  which  a  defined  need  exists  for 
contractual  support,  but  the  precise  nature,  quantity  or  schedule  of  the  effort  required  cannot  be 
determined  in  advance,  but  can  be  described  in  general  terms.  Contract  requirements  are  written  as 
definitively  as  possible  from  the  onset,  and  not  tailored  to  any  particular  approach. 

Caution;  These  descriptiorrs  have  been  provided  for  information  only,  to  help  determine  the 
steps  needed  to  place  the  identified  requirement  on  contract.  The  selection  of  an  existing  contract  is  not 
based  on  the  type  of  contract,  but  rather  if  the  identified  Phase  0  requirement  is  within  the  scope  of  the 
current  requirements  of  that  existing  contract. 

Schedule:  A  modification  to  an  existing  studies  contract  (other  than  a  task  order  contract)  can 
take  nearly  as  long  as  an  RFP.  The  steps  required  are  as  follows; 

1 .  Prepare  a  purchase  request  (PR)  with  related  documents,  (e.g.  SOW  modification), 

2.  solicite  the  requirement  to  the  contractor, 

3.  allow  the  contractor  time  to  prepare  and  submit  a  proposal, 

4.  after  receipt,  the  proposal  is  technically  reviewed  and  negotiated, 

5.  and  finally,  the  contract  is  modified,  reviewed  and  signed. 

Depending  on  the  complexity  of  the  requirement,  this  process  can  take  from  60  to  120  days,  with  90  days 
as  typical.  If  an  existing  task  order  contract  is  used,  it  may  take  as  tittle  as  30  days  to  place  a  new  task 
on  contract.  Although  all  of  the  abov^e  steps  must  also  be  followed  to  issue  a  task  order,  the  differerx:e  is 
that  the  contract  has  been  specifically  set  up  to  accept  defined  tasks  during  period  of  performance  stated 
in  the  contract.  Other  cost  reimbursement  contracts  have  the  effort  defined  at  the  beginning  of  the 
contract  and  modifying  the  effort  is  restricted. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  studies  procurement  activity  for  this  stage  of  the  project  does  not  usually  start 
until  the  contracting  strategy  has  been  approved  (D34  and  D22). 

b.  Exit:  This  effort  ends  when  the  Concept  Exploration  studies  contract(s)  are  awarded. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  The  input  data  needed  for  this  task  is  the  acquisition  strategy  (D22)  for  the  project 
and  irfoustry  involvement  (such  as  DRFP)(lndustry  Monitor  and/or  Participate  in  Government  Programs 
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Thfu  IR&D,  RFIs,  RFPs,  or  Other  Means).  This  intormation  will  provide  the  main  points  to  determine  the 
method  of  contracting  and  help  in  defining  the  requiremerrts  and  duration  of  effort. 

b.  Outputs:  Output  from  this  effort  will  provide  the  contractual  vehicle  to  provide  the  studies  for 
analysis  (037). 

10.  KEY  REFERENCES:  In  addition  to  the  documents  listed  in  the  above  Requirements  section, 
reference  include  ASC/CYXs  "A  Schedule  for  Acquisition  Hanning;  Initial  Acquisition  and  Strategy 
Development  Through  Source  Selection,*  HQ  AFSC  Request  for  Proposal  Process  Guide,  and  current 
ASC/PK  policy  letters. 

11.  IMPLEMENTATION  TOOLS:  ASC/CYX  has  guidance,  facilKies,  and  computer  resources  to  assist 
in  RFP  preparation  and  source  selection. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  This  entire  acquisition  action  can  take  up  to  1  year  from  draft  source  selection 
plan  to  award  of  the  contract.  This  alt  depends  on  the  complexity  and  dollar  anKMjnt  of  the  project  and 
whether  a  DRFP  is  utilized  or  not.  Preparation  and  approval  of  the  source  selection  plan  and 
concurrently  the  writing  and  release  of  the  DRFP  can  take  from  60  to  1 60  days.  Finalizing  the  RFP  and 
obtaining  approval  for  release  may  take  up  to  90  days.  The  standard  time  for  source  selection  (from 
RFP  release  to  contract  award)  can  be  no  nwre  than  120  days.  This  time  can  be  reduced  if  an  existing 
contractual  vehicle  is  used.  If  a  contract  is  used  that  must  have  the  SOW  modified,  the  average  time  will 
be  90  days.  The  complexity  of  the  effort  will  cause  the  time  to  increase.  If  a  task  order  type  contract  is 
used  the  amount  of  time  can  be  reduced  to  30  days.  This  is  dependent  upon  the  requirement  being 
ready  to  execute  and  the  full  cooperation  from  the  contractor. 

b.  CONSTRAINTS:  The  FAR  and  other  referenced  regulations  have  placed  minimum 
notification  times  for  reviews  and  publications.  On  all  major  programs  SAF/AQC  and  DAE  must  be 
notified  no  less  than  30  days  before  an  RFP  is  released.  A  Notice  of  Contract  Action  (NOCA)  must  be 
published  in  the  Comrrterce  Business  Daily  (CBD)  at  least  15  days  before  RFP  release.  It  is 
recommended  that  the  contractors  be  given  a  minimum  of  30  days  to  provide  comments  on  a  DRFP 
before  the  RFP  is  issued.  The  minimum  allowed  time  for  receipt  of  proposals  is  30  days  from  date  of 
issuarx:e  of  an  RFP,  (45  days  for  R&D  actions). 

An  audit  may  be  required  for  either  an  RFP  or  a  modification  to  an  existing  contract. 
Audits  are  required  for  all  efforts  $500,000  or  more.  The  CO  has  the  authority  to  waive  audits  up  to 
$2.0m  if  adequate  pricing  information  is  available.  If  an  audit  is  required,  the  auditor  has  60  days  to 
provide  a  report. 

Constraints  on  task  orders  may  vary  based  on  the  basic  contract  but  the  following  are 

common; 

(1) .  shall  not  exceed  $500K  and/or  a  duration  of  1 2  months, 

(2) .  shall  not  contain  more  than  50%  subcontracting, 

(3) .  shall  not  be  used  to  purchase  equipment  unless  necessary  to  accomplish  R&D 
(i.e.,  one-of-a-kind  prototype). 

c.  RESOURCES:  The  composition  of  the  source  selection  team  depends  upon  the  level  of 
complexity  and  perceived  risks  involved.  All  members  involved  with  the  development  of  the  contracting 
strategy  and  the  updating  of  that  strategy  (D34  and  D22)  should  be  included  on  the  team.  Additional 
personnel  should  irrclude  a  procurement  clerk  and  buyer,  if  not  already  involved,  and  other  functional 
experts  as  needed  tor  writing  of  the  RFP  and  as  reviewers  of  proposals.  ASC/CYX  should  be  contacted 
to  schedule  use  of  their  source  selection  facility  arto  RFP  development  computer  resources,  (as  needed). 
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It  an  existing  contractual  vehicle  is  used,  the  resources  provided  wHI  be  dependent  on 
the  owner  of  the  contract.  Ttx^  resources  should  be  augmented  in  the  area  of  project  officer 
(requirements  definition)  and  any  other  functional  areas  peculiar  to  the  effort. 

d.  LESSONS  LEARNED:  ASC/CYX  ntaintains  a  lessons  learned  date  base  for  aU  source 
selections  held  at  ASC.  Regular  updates  of  significant  lessons  learned  are  constantly  added  to  the  file. 
This  file  should  be  accessed  as  soon  as  a  source  selection  is  contemplated. 

One  of  the  most  common  mistakes  made  during  the  RFP  process  is  not  clearly  defining 
the  requirement.  Extra  care  and  time  should  be  taken  when  defining  the  requirement  as  any  changes 
after  the  source  selection  process  has  started  will  impact  the  schedule  or  could  cause  the  source 
selection  to  be  cancelled  and  restarted. 

If  an  existing  contractual  vehicle  is  used,  extreme  care  should  be  taken  to  make  sure 
that  the  proposed  additional  effort  is  within  the  scope  of  the  cun’ent  SOW  or  that  the  requested  task  order 
is  within  the  scope  of  the  basic  contract.  A  change  to  an  existing  contract  is  any  alteration  within  the 
contract  scope,  in  any  one  of  the  following: 

(1 ) .  Drawings,  designs  or  specifications  where  the  supplies  to  be  furnished  are  to  be 
specifically  manufactured  for  the  government, 

(2) .  Method  of  shipment  or  packing,  or 

(3) .  Place  of  delivery. 

e.  BEST  PRACTICES:  The  ASC/CYX  lessons  learned  files  should  be  reviewed  for  any  best 
practices  which  could  apply  to  each  studies  procurement  activity. 

f.  TRAPS:  Schedule  is  very  critical  to  this  activity.  Additional  time  should  be  kept  in 
management  reserve  for  unexpected  delays,  (i.e.  reviews  which  take  longer  than  expected, 
modifications  to  the  RFP). 
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1.  ELEMEWr:  D37,  TBS  1.2. 1.2  (IFC  Revision  93-3) 

2.  ELEMENT  TITLE:  Conduct  ConcefM  Exploration  Shxfes 

3.  ELEMENT  OWNER(S):  ASC/YX 

4.  ELEMENT  STAKEHOLDER(S):  Operating  Command,  Air  Force  Materiel  Command  (AFMC), 
Aeronautical  Systems  Center  (ASC).  Product  Center  XRs,  Industry,  Laboratories,  and  Other  Government 
Agencies. 

5.  REQUIREMENT: 

a.  OoDI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  Part  6,  Section  A 
aixl  Part  11,  Section  A. 

b.  MIL-STD-4996,  Systems  Engineering,  Section  3.8 

The  above  documents  outline  the  need  to  coixiuct  detail  technical  analyses  to  identity  and  evaluate 
alternative  concepts  that  satisfy  the  validated  need  and  the  direction  in  the  Acquisition  Decision 
Memorandum  (ADM)  and  Program  Management  Directive  (PMD). 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Concept  exploration  studies  are  the  initial  technical  activities  for  Phase  0  for 
evaluating  and  transforming  evolving  operational  requirements  into  system  level  requirements  (technical 
requirements)  arrd  continuing  the  evaluation  and  definition  of  alternative  concepts  identified  in  Pre- 
Milestone  0  activities  and  approved  for  continued  study  in  the  ADM  (element  A9)  and  the  PMD  (element 
«  BIO). 


b.  Objectives:  Concept  exploration  studies  focus  on  producing  the  technical  information 
required  for  requirements  generation,  further  development  and  evaluation  of  the  alternative  concepts 
and  for  generating  performance  data  for  use  in  conducting  follow-on  Program  AKematives  Analysis, 
element  D46  and  Cost  and  Operational  Effectiveness  Analysis  (COE A),  element  D48. 

7.  DESCRIPTION: 

a.  The  Process:  The  contemporary  Systems  Engineering  Process  (SEP)  outlined  in  MIL-STD- 
499B  and  other  Systems  Engineering  documents  (see  Key  References,  Para.  10)  provides  a  framework 
within  wNch  to  accomplish  coiicept  exploration  studies.  The  SEP  provides  a  disciplined  approach  by 
which  the  acquisition  community  (project  cadre)  conducts  all  technical  activities  necessary  to  evaluate 
evolving  operational  rer^irements,  identify  and  allocate  enabling  system  functions,  devel^  and  evaluate 
alternative  concepts  satisfying  those  functions  and  assess  system  performance  relative  to  the  Operating 
Command's  needs. 

b.  The  Focus:  The  concept  exploration  studies  provide  the  technical  basis  for  supporting 
requirements  generation  activities  aixl  linking  those  activities  to  alternative  corK;e|3t  exploration  arxf 
evaluation.  Critical  system  functions,  indicated  by  operational  requirement  inputs,  are  identified  and 
resolved  to  greater  detail  and  related  to  (satisfied  by)  specific  design  concepts  (technical  characteristics). 
The  studies  focus  on  evaluating  evolving  operational  requirements,  system  functions  and  associated 
system  techncal  characteristics  relative  to  cost,  schedule  and  technical  parameters  developed  to  assess 
concept  performance.  The  objectives  of  the  concept  exploration  studies  include: 

(1)  sujTporting  verification  (validation)  of  evolving  operational  requirements,  tracing  their 
origins  to  mission  needs 
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(2)  identification  and  sec^encing  of  system  level  functions  that  support  the  validated 
operational  requirements  (functional  identification) 

(3)  definition  and  allocation  of  those  functions  (requirements  allocation)  to  levels  of 
detail  sufficient  to  develop  (and  evaluate)  functional  architectures 

(4)  development  of  attemative  cortcepts  (gross  level  system  definition)  and  identification 
of  technology  needs  and  risks, 

(5)  and  evaluation  of  alternative  systents  for  their  ability  to  accomplish  indicated 
functions,  satisfy  operational  requirements  and  ultimately  mission  needs. 

This  last  objective  is  satisfied  through  trade  studies  that  employ  Measures  Of  Effectiveness  and 
Technical  Parameters  in  the  evaluation  of  the  system  performance  (considerirtg  the  critical  system 
elements:  equipment,  facilities,  personnel,  data,  and  software)  for  the  primary  life  cycle  phases 
(development,  manufacturing,  verification,  deployment,  operations,  support,  training,  and  disposal). 

c.  Initiation  and  Execution  of  Concept  Expioration  Studies:  Concept  exploration  studies  are 
initiated  with  a  close  examination  of  validated  needs  and  preliminary  operational  requirements 
(Operational  Requirements  Document.  ORD).  These  input  requirements  are  evaluated  against  a  set  of 
alternative  concepts  developed  prior  to  Pre-Milestone  0  activities  and  approved  for  further  study  during 
Phase  0.  Systems  functions  relating  operational  requirements  to  design  solutions  (alternative  concepts) 
are  updated/developed  from  previous  study  activities  and  evaluated  through  a  process  known  as  system 
requirements  analysis.  The  alternative  concepts  under  consideration  continue  to  be  described  in  greater 
detail,  commensurate  with  the  level  of  definition  of  the  system  functions  and  evaluated  for  their  suitability 
(effectiveness)  through  conceptual  design  studies  (design  synthesis).  The  interrelationship  between  the 
needs,  operational  requirements  and  technical  characteristics  (system  requirements)  evaluated  in  the 
various  concepts  are  compared  against  pre-established  measures  of  merit  and  technical  (performance) 
parameters  to  assess  the  effectiveness  of  the  concepts  under  consideration  and  provide  insight  into 
additional  study  opportunities,  technology  requirements  and  risks  (balance  and  control).  The  following 
discussion  describes  the  three  major  components  of  the  studies  activity  which  contribute  to  the 
development  of  system  requirements  arxl  definition  of  viable  alternative  concepts  for  evaluation  in 
follow-on  alternatives  analysis  (Conduct  Program  Alternatives  Analysis,  Element  D46  and  COEA, 
Element  D48). 


(1)  Requirements  Analysis:  The  focus  of  the  requirements  analysis  conducted  during 
concept  exploration  studies  is  on  identifying  and  defining  functions  (functional  requirements)  associated 
with  operational  requirements  (available  to  this  activity  from  element  C19,  Develop  Draft  ORD)  and 
allocating  those  functions  to  system  level  technical  characteristics.  Requirements  analysis  can  be 
viewed  as  a  two  step  process  aimed  at  relating  operational  requirements  to  viable  design  concepts 
(described  in  a  work  breakdown  structure)  via  system  functional  descriptions  (represented  in  a  functional 
architecture).  The  requirements  analysis  activity  serves  as  the  principle  link  between  the  operational 
command  activities  (mission  need  statement  preparation  and  operational  requirements  definition)  and 
the  developer's  task  of  identifying  and  evaluating  viable  conceptual  design  solutions.  The  requirements 
are  derived  tor  the  key  life  cycle  phases  and  address  critical  functions  including  supportability, 
maintainability,  deployability,  survivability,  and  training.  The  process  of  generating  the  system 
requirements  is  highly  interactive  with  the  development  of  operational  requirements;  definition  of  each  is 
influenced  by  the  analyses  conducted  in  the  conceptual  design  and  balance  and  control  activities.  A 
variety  of  analytical  methods  and  concepts  are  applied  in  identifying  and  allocating  functions  to  lower 
levels  and  consequently  defining  system  technical  characteristics  more  precisely. 

(a)  Functional  analysis  and  allocation  is  a  principle  component  of  requirements 
analysis  and  involves  the  identification  and  evaluation  of  top  level  functions  and  subfunctions  meeting 
stat^  operational  requirements  for  a  variety  of  alternative  concepts.  Functional  Flow  Block  Diagrams 
(FFBDs)  are  used  to  demonstrate  the  interrelationships  of  each  function  and  associated  subfunctions 
with  one  another  and  the  system.  Time  Line  Sheets  (TLSs)  are  used  to  represent  functional  sequencing 
and  time  critical  relationships.  The  process  of  defining  functions  at  lower  levels  of  detail  is  accomplished 
by  the  Requirements  Allocation  Sheet  (RAS)  which  has  three  principle  purposes:  to  record  performarxte 
requirements  established  for  each  function  during  synthesis,  to  show  the  allocation  of  functional 
requirements  to  individual  system  elements  or  combinations  of  elements  and  to  derive  the  functionally 
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oriented  data  used  in  describing  the  system.  An  output  of  the  process  that  identifies  nuttipie  levels  of 
functions  (requirements  allocation)  and  their  relationships  is  commonly  referred  to  as  the  ^nctional 
architecture.  The  functional  architecture  is  useful  for  identifying/refining  design  concepts  and  serves  as 
a  baseline  for  assessing  functionality  and  for  conducting  trades  on  performance  (functions,  cost, 
schedule,  risk),  for  assessing  the  feasibility  of  achieving  the  requirements  and  establishing/confirming  the 
validity  of  esKih  design.  System  level  requirements  established  (informally)  during  Pre-Milestone  0 
activities  are  formally  recognized,  updat^  and  consolidated  in  a  preliminary  Systems  Requirements 
Document  (SRD)  as  a  result  of  these  analyses. 

(2)  Conceptual  Design  (Synthesis):  The  synthesis  activity  produces  corx^eptual  designs 
to  implement  evolving  functional  architectures  and  provides  information  for  evaluating  the  capability  of 
those  designs  to  satisfy  evolving  system  requirements  (contained  in  the  SRD)  and  operational 
requirements  (contained  in  the  ORD).  Conceptual  design  studies  address  the  total  system  (system 
elements)  in  the  context  of  the  life  cycle  phases  and  develop  the  alternative  designs  to  a  level  of  detail  to 
support. 

(a)  cost  schedule  and  performarrce  evaluations. 

(b)  implementation  of  a  risk  management  plan  (risk  identification,  evaluation 

and  control), 

(c)  identification  of  critical  technology  requirements  (including  products, 
processes  and  materials). 

Two  widely  used  tools  to  accomplish  the  synthesis  of  design  concepts  are  the  Concept  Description  Sheet 
(CDS)  and  the  Schematic  Block  Diagram  (SBD).  The  CDS  is  used  to  collect  performance  requirements 
and  constraints  (identified  in  functional  analysis)  and  describe  technical  characteristics  that  satisfy  those 
requirements.  It  conveys  a  gross  level  of  design  demonstrating  compliance  with  the  allocated 
requirements,  time  line  sheets  and  the  functional  flow  block  diagram.  The  SBD  serves  as  the  basis  for 
models  of  the  evolving  system  and: 

(d)  depicts  a  complete  response  to  the  functional  requirements. 

(e)  depicts  compatibility  between  elements  of  the  system  and  interfacing 

systems/subsystems 

(f)  provides  traceability  between  system  elements  and  their  functional  origin  and 

(g)  provides  a  mechanism  for  complete  and  comprehensive  change  control  (i.e. 
the  SBD  can  be  used  later  (in  element  D37B,  Conduct  Concept  Definition  for  Preferred  Alternatives)  to 
develop  the  Interface  Control  Documents,  ICDs)  for  each  design  concept. 

(h)  functions  that  are  not  well  defined  and/or  cannot  be  completely  described  by 
physical  models  are  identified  for  further  evaluation  by  a  technology  development  activity  (output  to 
element  D43,  Assess  Technology  Needs) 

(3)  Balance  &  Control  describes  the  set  of  activities  associated  with  evaluating  the 
derived  system  requirements,  assessing  the  performance  of  the  alternative  design  concepts  under 
consideration  and  formulating  recommendations  regardirig  the  nx>st  promising  alternatives.  This 
evaluation  and  decision  activity  is  supported  through  trade  studies  (trade-off  analyses)  and  deals  with 
issues  pertaining  to  risk  management,  configuration  management,  technology  programs  and  plans, 
manufacturing  technologies,  environmental  management  and  performance-tesed  progress 
measurement  activities.  The  analyses  accomplished  at  this  point  in  the  process  also  identifies 
alternatives  that  represent  less  than  1 00%  solutions  and  the  degree  of  shortfalls. 

(a)  Trade  studies  are  conducted  on  each  alternative  to:  1)  establish  functional 
requirements  and  technical  characteristics,  2)  evaluate  the  resulting  functional  architectures,  3)  examine 
alternative  technology  strategies  and  risk  abatement  approaches,  and  4)  evaluate  gross  levels  of  design 
to  support  identification  of  preferred  products  and  processes. 

(b)  Risk  management  activities  include  identifying  and  quantifying  technical  risk 
in  terms  of  cost,  schedule,  and  performance  for  each  alternative  concept  under  study.  Technology 
application  risks  (products  and  processes)  are  identified  and  quantified  at  a  level  commensurate  with  the 
level  of  detail  for  each  concept  under  consideration.  The  risks  associated  with  interface  characteristics 
of  the  functional  architecture  (both  internal  and  external)  are  also  quantified.  Risk  control  plans  are 
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developedAjpdated  as  the  designs  are  iterated  and  include  strategies  and  concept  specific  risk 
abatement  activities. 


(c)  Configuration  management  activities  include  developing  preliminary 
configuration  and  data  management  plans  and  supporting  continuing  development  of  the  System 
Requirements  Document  (SRO)  and  Baseline  Coricept  Desc^bns  (BCDs).  In  support  of  follow-on 
concept  definition  activity  (element  D37B),  system  characteristics  will  evolve  sufficiently  to  warrant 
creation  of  Interface  Control  Working  Groups  (ICWGs)  for  coordinating  systems  engineering  activities 
across  system  and  subsystem  interfaces. 

(d)  Critical  (existing)  technology  capabilities  are  evaluated  during  the  concept 
explorations  studies  for  their  potential  application  to  the  evolving  systems  and  critical  technology 
shortfalls  (enabling  technologies)  are  identified.  Continuous  technical  interchange  between  the  project 
cadre  and  laboratories  and  industry  offering  enabling  technologies  are  necessary  in  order  to  assess  the 
viability  of  some  of  the  high  risk  concepts  being  explored  and  provide  guidar^e  regarding  potential  future 
technology  investments.  Element  D43,  Assess  Technology  Needs  transfomns  system  requirements 
judged  to  be  unachievable  with  current  technologies  aixf  characterizes  those  deficiencies  in  terms  of 
technology  needs  for  investment  by  the  laboratories. 

(e)  Manufacturing  Capabilities  Requirements  (MCR)  is  a  process  (tool)  used  to 
identify  and  evaluate  manufacturing  technologies,  product  and  process  characteristics  and  industrial 
base  capabilities  deemed  necessary  for  system  development  and  support.  This  assessment  reviews  in 
detail,  each  alternative  concept  under  consideration  arid  evaluates  the  impact  from  materials, 
components,  tooling  and  equipment  and  processing  techniques.  The  MCR  assessment  sen/es  as  basis 
for  developing  program  manufacturing  strategy  and  risk  reduction  approaches;  these  are  updated  as  the 
program  and  concepts  mature. 

(f)  Environmental  Management  is  evolving  as  a  major  consideration  for  weapon 
system  acquisition  and  requires  the  development  of  an  environmental  management  strategy  and  plans. 
Standards  for  the  use  of  hazardous  materials  and  pollutants  continue  to  be  tightened  and  represent  a 
major  design  consideration  affecting  system  performance  throughout  its  life  cycle.  Alternative  design 
concepts  and  the  driving  system  characteristics  must  be  evaluated  against  existing  and  projected 
environmental  starbards  early,  to  address  design,  development,  testing,  deployment,  and  supportability 
challenges  posed  by  these  standards. 

(g)  A  Logistics  Support  Analysis  Strategy  (LSAS)  informally  dratted  in  Pre- 
Milestone  0  activities  and  formalized  in  the  plans  update  at  the  b^inning  of  Phase  0  (element  D23, 
Update  Phase  0  Technical  Plans)  serves  as  a  basis  for  assessing  supportability  (operability, 
maintainability,  training,  management)  requirements  (objectives)  during  the  concept  exploration  studies. 
The  principle  focus  of  the  strategy  includes  support  objectives,  goals,  thresholds,  design  and  support 
criteria,  support  concepts  (logistics  tail),  maintenance  concepts,  training  concepts,  staffing  (personnel) 
and  target  improvements  over  existing  systems.  An  early  version  of  the  Integrated  Logistics  Support 
Plan  (ILSP),  which  serves  as  a  road  map  for  implementation  of  the  LSAS  is  also  developed  concurrent 
with  evolution  of  the  operational  requirements.  The  supportability  function  addresses  those  tasks, 
actions,  activities,  and  associated  system  elements  which  facilitate  operations  maintenance,  logistics 
(and  training)  and  materiel  management.  The  support  function  as  described  in  the  ILSP,  provides 
definition  for  tasks,  equipment,  skills,  personnel,  facilities,  materials,  senrices,  supplies,  and  procedures 
required  to  ensure  actuate  system  performance. 

(h)  For  each  alternative  concept  under  consideration,  technology  assessments 
are  corxfucted  to  identify  critical  technologies  to  the  level  of  definition  of  each  concept.  These  critical 
technologies  are  evaluated  against  what  is  currently  available  or  projected  to  be  available.  Shortfalls  are 
identified  as  technology  needs  (inputs  to  Assess  Technology  Needs,  element  D43)  for  potential  addition 
to  government  laboratories'  and  industrial  base  research  and  development  activities.  This  activity 
requires  a  sustained  interface  between  the  project  team,  government  laboratories,  product  centers 
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(across  all  services)  and  irKiustry  and  includes  a  consideration  for  Non-developmental  Items  (element 
D27)  and  Cooperative  Development  Programs  (element  D28). 

(i)  Effectiveness  analysis  is  a  principle  element  of  the  balance  and  control 
activity,  providing  qualitative  and  quantitative  ratings  on  the  performance  of  the  alternative  concepts 
under  consideration.  Predetermined  performance  metrics,  referred  to  as  Measures  Of  Effectiveness 
(MOEs)  serve  as  benchmarks  against  which  alternative  concepts  operational  cap^lities  are  appraised. 
Potential  sources  of  inputs  for  developing  MOEs  for  use  in  the  evaluation  activity  include  selection 
criteria  employed  during  Pre-Milestone  0  concept  studies  and  analysis,  the  Mission  Need  Statement  and 
Milestone  0  decision  documentation  (including  Acquisition  Decision  Memorandum,  ADM  and  Program 
Management  Directive,  PMD).  The  focus  is  on  the  total  system  (equipment,  facilities,  personnel,  data 
and  software)  and  effectiveness  is  assessed  throughout  the  life  cycle  (development,  manufacturing, 
verification,  deployment,  operations,  support,  training  and  disposal  phases).  Subsequent  iterations 
through  requirements  analyses  and  design  synthesis  are  driven  by  the  results  of  the  eftectiveness 
analysis. 


(j)  Performance  based  progress  management  describes  the  underlying 
philosophy  for  the  contemporary  systems  engineering  process  and  involves  the  development  and 
application  of  event  driven  milestones.  This  is  a  major  consideration  during  balance  and  control 
activities  arKf  provides  specific  exit  criteria  for  concept  exploration  studies.  Updates  to  the  Systems 
Engineering  Management  Plan  (SEMP)  and  Systems  Engineering  Master  Schedule  (SEMS)  are 
accomplished  as  a  part  of  the  balance  and  control  activities.  Specific  criteria  developed  and 
documented  in  the  SEMS  is  used  as  a  basis  for  determining  when  each  design  concept  has  been  defined 
to  the  necessary  level  of  detail  and  characterizes  the  performance  of  each  concept  as  measured  by 
predetermined  Technical  Parameters  (TPs)  evaluated  on  a  continuing  basis  through  Technical 
Performance  Measurement  (TPM).  Technical  parameters  are  a  select  set  of  system  technical  metrics 
chosen  by  management  to  track  development  progress;  TPs  are  identified  through  and  support  risk 
analyses,  contract  specifications  and  contracting  strategy.  The  process  of  continuously  assessing  the 

f  degree  of  anticipated  and  actual  achievement  of  TPs  is  referred  to  as  TPM.  Technical  performance 

measurement  provides  insight  into  design  deficiencies  and  provides  an  indication  of  the  potential  impact 
on  system  level  requirements.  The  TPM  process  provides  visibility  into  actual  versus  planned 
performance,  early  detection  or  prediction  of  problems  which  require  management  attention  and  an 
assessment  of  the  program  impact  resulting  from  proposed  change,  alternatives. 

(k)  The  trade  study  activities  culminate  in  the  publication  of  Trade  Study 
Reports  (TSRs)  which  identify  and  characterize  promising  concepts,  document  the  results  of  significant 
trades,  identify  study  assumptions  and  constraints,  provide  an  assessment  of  concept  risks  and  methods 
of  abatement  and  dement  rationale  used  in  the  decision  process. 

d.  Study  Progress  and  Conclusion  (Process  Iteration);  The  performance  based  progress 
management  process  referenced  in  7.c.(3)(g),  and  implemented  via  the  SEMS  serves  as  a  basis  for 
evaluating  progress  and  establishing  when  the  studies  should  be  brought  to  a  conclusion.  The 
completed  trade  study  reports,  are  a  principle  component  of  the  data  package  produced  during  concept 
exploration  studies  and  forwarded  to  the  Alternative  Systems  Review  (ASR),  element  D45.  This  review 
evaluates  the  content  of  those  reports,  reviews  the  results  of  the  studies  in  the  context  of  the  exit  criteria 
established  in  the  SEMS  and  validates  the  data  generated.  Further  concept  refinement  (to  the  system 
subcomponent  level)  will  be  provided  on  a  preferred  set  of  alternatives  evaluated  in  element  D37B, 
Conduct  Concept  Definition  for  Preferred  Alternatives. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Concept  exploration  studies  can  be  initiated  once  Phase  0  technical  and 
programmatic  plans  have  been  updated  and  approved. 

(1)  Work  statements  for  Phase  0  are  current. 

(2)  Preliminary  Cost  and  Operational  Effectiveness  Analysis  (COEA)  plan  is  drafted. 
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(3)  Initial,  top  level  operational  and  system  requirements  must  be  identified  and 

documented 


(a)  Draft  Operational  Requirements  Document  (ORD1 ),  including  preliminary 
Requirements  Correlation  Matrix  data  (operational  obiectives  and  threshold  values  for  significant 
operational  characteristics  must  be  available). 

(b)  A  draft  System  Requiremertts  Document  (SRD);  The  data  developed  in 
support  of  the  Mission  Needs  Analysis  conducted  during  Pre-Milestone  0  activities  represents  the 
principle  mputs  to  the  first  draft  of  the  SRD. 

(4)  An  initial  Baseline  Concept  Description  is  prepared/updated  for  each  alternative 
concept  to  be  studied. 

(5)  A  draft  Systems  Engineering  Management  Plan  and  Systems  Engineering  Master 
Schedule  is  F>repared  by  the  government  project  team. 

(6)  The  contracting  strategy  (vehicle)  and  budgetary  requirements  to  support  contracted 
studies  must  be  satisfied. 

b.  Exit:  Concept  Exploration  Studies  are  concluded  once  it  has  been  established  that  the  project 
milestones  identified  in  the  SEMS  have  been  met.  that  all  technical  plans  have  been  updated  (including 
the  SEMS)  and  support  the  SEMP  and  that  the  developing  and  operating  command  are  satisfi^  with  the 
information  (data)  produced  by  this  activity.  A  formal  assessment  (and  decision  to  proceed)  will  be 
accomplish^  during  the  Alternative  Systems  Review  (ASR),  element  D45. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs; 

(1)  Mission  Need  Statement:  Provides  a  frame  of  reference  within  which  to  assess  the 
relevance  of  the  operational  requirements  and  consequently  the  adequacy  of  the  system  requirements 
being  generated. 

(2)  Draft  ORD1 :  Establishes  operational  objectives  and  thresholds  for  use  in  identifying 
functions  and  corresponding  system  level  requirements. 

(3)  Draft  SRD:  Identifies  technical  characteristics  for  continuing  functional  analysis, 
development  of  technical  characteristics  and  definition  and  evaluation  of  alternative  concepts  and 
enabling  technologies. 

(4)  Draft  SEMP/SEMS:  The  SEMP  provides  information  on  the  overall  systems 
engineering  plan  for  the  program  (project)  and  the  SEMS  provides  specific  event  driven  milestones  and 
performance  based  technical  parameters  against  which  to  evaluate  progress  made  in  the  studies. 

(5)  Draft  BCD;  A  draft  BCD  for  each  concept  should  be  available  to  document  evolving 
requirements,  technical  characteristics  and  design  features. 

(6)  Contracting  Strategy  (contracting  vehicle);  A  contracting  vehicle  must  be  identified 
arxf  enforceable  for  contracted  concept  exploration  studies. 

(7)  Task  descriptions  (Statements  Of  Work,  SOWs)  for  studies  must  be  identified  and 
supported  by  a  contracting  strategy  (vehicle). 

b.  Outputs; 

(1 )  Functional  architecture  for  each  alternative  conceptual  design. 

(2)  Updated  Baseline  Concept  Descriptions  for  each  concept. 

(3)  Critical  technologies  list. 

(4)  Updated  System  Requirements  Document. 

(5)  Concept  Risk  Assessments  addressing  (products  and  processes,  system 
performance,  sch^ule  and  cost). 

(6)  Trade  Study  Report  summarizing  results  of  concept  exploration  activities. 

(7)  Source  Data  for  Updating  Technical  Documentation:  SEMP,  SEMS.  LSAS,  MCR. 

(8)  Other  Data  (Documentation)  including: 
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(a)  Functional  Analysis  Data;  FFBDs,  TLs,  CDSs,  SBOs 

(b)  Draft  specification  tree 

(c)  Initial  Work  Breakdown  Stoictures  (WBSs) 

(d)  Initial  facility  requirements  arxJ  processes  documentation. 

10.  KEY  REFERENCES:  MIL-HDBK-499-3,  Systems  Er^ineering/Configuration  Management  Guide  for 
Life  Cycle  Management,  Sections  C-5  through  C-13,  provides  an  overview  of  one  approach  to  preparing 
for  and  conducting  concept  exploration  studies.  The  Defense  Systems  Management  College  (DSMC) 
Systems  Engineering  manual  describes  classic  system  engineering  activities  and  provides  a  framework 
within  which  to  conduct  the  studies  and  document  the  information.  The  AFMC  Acquisition  Risk 
Management  Guide.  20  Aug  92  provides  comprehensive  guidance  on  risk  management. 

11.  IMPLEMENTATION  TOOLS:  Several  tools  are  identified  in  Para.  7  for  accomplishing  the  tasks  in 
this  element.  A  summary  of  these  tools  are  listed  here  along  with  a  brief  description  of  their  use; 

a.  Concept  Design  Sheet.  Used  to  collect  performance  requirements  and  constraints  (identified 
in  functional  analysis)  and  describe  technical  approaches  for  satisfying  those  requirements. 

b.  Functional  Architecture;  Process  of  arranging  functions/subfunctions  in  a  hierarchy,  showing 
internal  and  external  functional  and  physical  interfaces. 

c.  Functional  Flow  Block  Diagram;  Layered  matrices  showing  the  sequential  interface 
relationships  for  the  functions  in  a  system. 

d.  Interface  Control  Document;  A  document  that  describes  system/subsystem  interface  design 
implementation  of  the  requirements.  The  ICD  is  a  repository  for  interface  definition  data  (including 
drawings,  sketches,  functional  lists,  procedures  arxf  processes,  equations,  etc.)  for  use  in  designing  the 
interface. 

e.  N  Squared  Diagrams;  Matrix  used  to  identify/summarize  the  interaction  of  functional  data 
interfaces  and  system  inputs  and  outputs. 

f.  Schematic  Block  Diagram;  Used  as  the  basis  for  models  of  the  evolving  system;  this  tool; 

(1 )  depicts  a  complete  response  to  the  functional  need. 

(2)  depicts  compatibility  between  elements  of  the  system  and  interfacing 
systenrysubsystems, 

(3)  provides  traceability  between  system  elements  and  their  functional  origin  and 

(4)  provides  a  mechanism  for  complete  and  comprehensive  change  control,  (i.e.  SBD  is 
used  to  develop  the  ICDs)  for  each  design  concept. 

g.  Systems  Engineering  Management  Plan;  A  con^rehensive  document  that  describes  how  the 
fully  integrated  engineeririg  effort  will  be  managed  and  corxlucted. 

h.  Systems  Engineering  Master  Schedule;  A  compilation  of  key  accomplishments  requiring 
successful  completion  to  pass  identified  events.  Acconplishments  include  major  and  critical  tasks, 
activities  aixf  demonstrations,  with  associated  criteria. 

i  Technical  Performance  Measures;  A  select  set  of  critical  system  technical  metrics  tracked  for 
verification  of  the  degree  of  anticipated  versus  actual  achievement. 

j.  Time  Line  Sheets;  Tabular  data  summarizing  projected/actual  times  for  accomplishing  related 
and/or  interactive  tasks. 

12.  PLANNING  GUIDANCE:  Prior  to  initiating  this  activity,  predecessor  program  development  activities 
judged  to  be  of  similar  scope  should  be  investigated  for  lessons  learned,  best  practices,  resource 
requirements,  and  duration.  This  information  should  be  included  in  program  planning  activity  including 
development/update  of  the  Systems  Engineering  Management  Plan  and  Systems  Engineering  Master 
Schedule  supporting  this  activity  and  follow-on  activities  in  this  phase. 

a.  DURATION:  The  duration  of  the  concept  exploration  activity  is  a  function  of  the  scope  of  the 
need,  the  complexity  of  the  system  characteristics  (functions  and  requirements)  and  the  number  of 
alternative  concepts  under  consideration.  Concept  exploration  could  take  from  several  rTX>nths  (small 


number  of  akemative  solutions  to  a  simple  operational  requirement  and  need)  to  one  and  a  half  to  two 
years  (for  a  complex  set  of  requirements  involving  many  alternative  concepts). 


b.  CONSTRAINTS:  Time  and  program  funds  are  predictable  constraints  that  will  bound  the 
concept  exploration  studies  activities.  Inadequate  definition  of  operational  requirements,  poorly 
planned/documented  programmatic/technical  approach  will  complicate  the  studies  and  diversely  impact 
schedule  and  the  quality  of  the  study  results.  The  proper  resources  in  the  right  numbers  must  be 
identified  and  available  to  support  the  studies. 

c.  RESOURCES:  The  size  and  functional  makeup  of  the  staff  assigned  to  this  activity  will  vary 
depending  upon  the  system  requirements  (technical  and  programmatic).  The  use  of  personnel  with  prior 
experience  in  the  analyses  conducted  during  Pre-Milestone  0  activities  should  facilitate  the  transition  of 
the  project  through  Milestone  0  and  enhance  the  quality  of  the  product  of  this  studies  effort. 

d.  LESSONS  LEARNED:  The  Air  Force  Lessons  Learned  Database  may  be  consulted  via 
Automated  Lessons  Learned  Capture  and  Retrieval  System  (ALLCARS).  At  the  time  this  data  sheet  was 
drafted,  no  lessons  learned  pertaining  to  conducting  concept  exploration  studies  were  available. 

e.  BEST  PRACTICES: 

(1)  Design; 


(a)  Measurable  design  parameters  must  be  established. 

(b)  System  requirements  are  specified  and  allocated  based  on  function. 

(c)  All  relevant  system  requirements  are  properly  flowed  down. 

(2)  Trade  Studies: 

(a)  Trade  studies  should  be  iterative. 

(b)  Technology  needs  and  risks  should  be  identified. 

(c)  Development,  producibilrty,  deployability,  operability,  supportabilky  and 
reliability  should  be  considered.  The  focus  of  trade  studies  is  on  quantifying  cost,  schedule,  and 
performance. 


(3)  Planning/Implementation: 

(a)  The  programmatic  and  technical  objectives  of  concept  exploration  activities 
are  clearly  defined  and  documented  prior  to  conducting  the  studies. 

(b)  Proven  techniques  (tools)  are  enployed  in  a  disciplined  manner  when 

conducting  the  studies. 

(c)  Study  results,  assumptions  arxf  constraints  must  be  documented  in  a  formal 

data  base  for  future  use. 

(d)  Event  based  milestones,  clearly  defined  success  criteria  and  (baseline) 
technical  performance  measures  should  be  employed. 

f.  TRAPS:  The  concept  exploration  studies  activities  must  be  approached  in  a  systematic  and 
disciplined  manrter  to  ensure  that  the  solutions  explored  satisfy  the  functional  and  operational 
requirements  and  ultimately,  mission  needs.  Technology  needs  for  each  akemative  solution  must  be 
clearly  identified  and  program  cost,  arxd  schedule  risk  associated  with  these  deficiencies  must  be 
realistically  characterized. 
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1.  ELEMEKT:  D37B.  TBS  1.2.4. 1  (tFC93-3) 

2.  ELEMENT  TITLE:  Conduct  Concept  Definition  for  Preferred  Allemative<s) 

3.  ELEMENT  OWNER(S):  ASC/YX  or  Product  Center  XR 

4.  ELEMENT  STAKEHOLOER(S):  Operating  Command.  Air  Force  Materiel  Command  (AFMC), 
Product  Centers,  Air  Logistic  Centers  (ALCs).  Industry,  Laboratories,  and  Other  Government  Agencies. 

5.  REQUIREMENT:  DODI  5000.2,  PARTS  3  &  4,  ALL  SECTIONS  AND  PART  6,  SECTION  A. 
MIL-STD-49gB.  SYSTEMS  ENGINEERING.  PARA  3.8 


6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Further  defirte  the  preferred  concepts  selected  as  most  promising  by  the  MAJCOM  ^ 

as  part  of  C  25  activities. 

b.  Objectives:  The  objectives  of  this  activity  are  to: 

1 )  further  define  the  system  concepts  to  the  subsystem  and  major  component  level  to 

support  a  Milestone  I  decision,  ^ 

2) provide  the  source  information  to  prepare  or  update/refine  the  concept  and 
programmatic  documentation  (e.g.  BCD,  SRD.SEMP.SEMS.TEMP.ILSP.  COEA.etc.)  based  on  the 
additional  level  of  subsystem  information  and  programmatic  planning  developed  during  this  activity. 

(The  actual  preparation  or  update  of  some  docuntentation  may  be  accomplished  within  other  blocks. 

Refer  to  the  process  flow  chart  and  the  related  data  sheets.) 

I  •  • 

3)  provide  the  technical  and  programmatic  information  needed  to  support  the  preparation 
of  the  cost  analysis  requirements  description  (CARD)  and  program  cost  estimate  to  support  the 
POM/BES  submittal  for  the  project  and  the  Milestone  I  decision  process. 

7.  DESCRIPTION: 

• 

a.  The  Process:  The  contemporary  Systems  Engineering  Process  (SEP)  outlined  in  MIL-STD- 
499B  and  other  Systems  Engineering  documents  (see  Key  References,  Para.  10)  provides  a  framework 
within  which  to  acco^ish  concept  definition.  The  SEP  provides  a  disciplined  approach  by  which  the 
acquisition  community  (project  cadre)  conducts  all  technical  activities  necessary  to  1 )  evaluate  evolving 
operational  requirements,  2)  identify  and  allocate  enabling  system  and  subsystem  functions,  3)  develop. 

evaluate,,  and  define  alternative  concepts  satisfying  those  functions  and  4)  estimate  the  resulting  system  • 

performance  relative  to  the  Operating  Command's  needs  arxj  evolving  operational  requirements. 

b.  The  Focus:  The  concept  definition  effort  provides  the  technical  basis  for  supporting  both  the 
requirements  generation  and  acquisKion  management  system  activities  and  linking  those  activities  to 
alternative  concepts  (incfoding  support  concepts)  that  will  best  meet  user  needs.  Critical  system 

functions  are  ideritifi^  from  the  functional  architectures  and  are  translated  into  physical  conceptual  ^ 

designs  defined  to  greater  detail,  (i.e.  subsystem  arxf  major  component  level).  The  concept  definition 

effort  includes  evaluating  evolving  operational  requirements,  defining  system  and  subsystem  functions, 

technical  characteristics  and  technical  performance  parameters  (including  supportability  parameters)  that 

yield  the  needed  operational  utility  and  identifies  their  relationship  to  cost  and  schedule. 

c.  Initiation  and  Execution  of  Concept  Definition;  The  concept  definition  effort  is  essentially 

identical  to  the  effort  contained  in  Block  D  37  except  it  is  evolving  the  system  definition  through  * 

corveptual  design  to  include  the  concepts  for  the  subsystems  and  major  components  that  make  up  the 
alternatives.  The  concepts  will  be  further  developed  from  the  definition  achieved  during  the  concept 
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exploration  block  such  that  they  continue  to  represent  a  reasonable  balance  between  the  user's  stated 
needs  and  evolvinQ  operational  and  suooort  requirements  and  the  technology  available  or  needed  to 
implement  that  aHemative.  The  WBS  level  3  subsystems  would  be  defined  conceptually  to  convey  the 
content  of  that  system  alternative  so  that  decision  makers  and  users  can  visualize  arxf  urKferstand  the 
general  characteristics,  strengths  (pros)  and  weaknesses  (cons)  of  each  system  concept  along  with  the 
technical  requirements  that  would  have  to  be  met  to  satisfy  the  users  operational  requirements. 

Although  only  a  partial  listing,  the  definition  would  contain  the  following  types  of  information  (either 
original  or  updates  to  D37  info): 

1 )  Updates  to  allocated  weights 

2)  Revised  system  center  of  gravity  and  mass  distribution  estimates 

3)  Revisions  to  key  contours  and  shapes  critical  to  aerodynamic,  propulsion  or  signature 
performance 

4)  Revised  volume  estimates  and  space  allocations 

5)  Power  estimates  and  allocations 

6)  Initial  interface  control  documents  (ICDs) 

7)  Development  or  design  standards  (US,  NATO) 

8)  Performance  estimates  with  properties/characteristics  of  planned  subsystems  and  major 
components 

9)  Takeoff  and  landing  performance  estimates 

10)  Maneuvering  and  agility  predictions 

11)  RM&D  requirements,  characteristics  and  estimates 

12)  Supportability  requirements,  characteristics  and  estimates 

13)  Industrial  base  requiremetns  and  producibility  characteristics 

14)  Identification  of  performance  within  the  electromagnetic  spectrum 

15)  Defensive  and  offensive  avionics  system  requirements,  capabilities  and  characteristics 

16)  Communication  and  navigation  requirements,  capabilities  and  characteristics 

17)  Structural  concepts,  requirements  and  capabilities 

18)  Strutural  durability  requirements  and  characteristics 

19)  Weapons  carry  and  weapons  delivery  requirements  and  capabilities 

20)  etc. 

This  definition  would  also  include  the  material,  product  or  process  technologies  needed  to  fulfill  the 
requirements  along  with  a  risk  assessment  that  clearly  identifies  the  risk  areas  for  that  alternative.  In 
addition,  the  information  needed  to  prepare  the  SEMP  and  SEMS  for  that  alternative  and  the  technical 
information/parametrics  that  supports  estimating  the  life  cycle  cost  (LCC)  of  that  conceptual  "system" 
must  be  developed  during  this  block  activity.  The  SEMS  is  a  concept  that  provides  the  integrated 
planning  which  defines,  up  front,  all  the  diverse  systems  engineering  and  program  management  tasks 
and  events  that  must  be  accomplished  to  meet  the  user's  needs.  It  identifies  the  interrelationships  with 
the  program  milestones  and  schedule,  and  includes  the  entrance  and  exit  criteria  to  be  used  to  track  and 
measure  successful  task  completion  so  the  ptogram  is  event  driven  rather  than  schedule  driven. 

Different  terms  are/have  been  used  to  identify  the  SEMS.  (e.g.  the  Advanced  Tactical  Fighter  program 
used  the  term  Integrated  Master  Plan)(IMP))  so  you  are  free  to  use  another  term/acronym  that  you 
believe  better  reflects  the  content  or  purpose  of  the  SEMS. 

The  use  of  nondevelopmental  items  at  the  system,  subsystem  and  major  component  level  within  the 
alternative  concepts  will  be  described  along  with  the  strengths  and  constraints  they  impose  on  the  overall 
conceptual  system  and  the  planned  program. 


The  conceptual  "systems"  will  be  reviewed  during  the  Preferred  Alternatives  Review  (PAR)  (D  45B)  to 
this  level  of  detail,  (i.e.  WBS  level  3  or  below)  to  ensure  a  consistency  in  content  and  level  of  detail. 

The  concept  and  project  documentation,  (e.g.  BCD.  SRD,  etc)  will  be  refined/updated  as  a  part  of  the 
activity  accomplished  in  this  block  to  reflect  the  most  current  programmatic  definition  and  conceptual 
system  requirements.  Other  project  documentation/functional  plans,  (e.g.  SEMP,  SEMS,  TEMP  ILSP, 
COEA,  etc.)  will  be  jxepared  or  updated  as  a  part  of  activity  associated  with  other  blocks  in  the  process 
flow. 
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The  traceabdily  of  how  the  conceptual  system  evolved  from  the  needs,  to  operational  requirements  and 
finally  to  technical  requirements  for  the  system  and  the  subsystems  will  be  managed/tracked  as  part  of 
the  system  configuration  management  responsibilities  and  is  maintained  as  a  part  of  the  project 
database  (Bit  D  73). 

Substantial  amounts  of  technical  information  are  developed  as  part  of  requirements  and  hjnctbnal 
analyses,  design  synthesis,  and  trade  off  analyses  performed  at  the  system  and  subsystem  level  and  is 
used  to  support  evaluation  of  the  operational  effectiveness  of  each  altemative.  These  analyses  will  be 
guided  by  the  users  operational  constraints,  the  thresholds  and  objectives,  the  maximum  cost  and 
minimum  performance  that  have  been  identified  in  the  COEA  (BIk  48).  The  team  working  this  element 
must  coordinate  with  the  MAJCOM  personnel  preparing  the  COEA  i  Report  (BIks  C2S  &  048). 

Operational  requirements  will  be  refined  and  translated  into  techrucal  requirements  at  the  system  and 
subsystem/major  component  level.  These  technical  requirements  will  be  identified  in  the  s^em 
requirements  document  (SRD)  for  that  system  concept.  One  or  nxxe  of  these  conceptual  ‘systems" 
could  be  developed  further  during  the  demonstration/validation  phase  based  on  the  results  of  the 
Milestone  I  decision. 

The  operational  capabilities/effectiveness  of  each  cortceptual  ’system"  will  be  defined  and  compared  to 
the  user's  stated  needs/requirements  by  using  the  systems  engineering  process  to  analytically  verify  that 
the  system  is  mission  capable  and  any  limitations/trade  offs  are  acceptable  to  the  user.  This  assessment 
must  be  based  on  objective  analysis  that  supports  a  conclusion  that  the  conceptual  system  being 
described  will  satisfy  the  stated  operational  and  technical  requirements  (any  exceptions  need  to  be 
clearly  identified)  along  with  the  program  costs  for  that  altemative.  System  concepts  that  do  not  totally 
meet  the  user's  needs/requirements  should  not  be  rejected  prematurely  if  they  offer  significant  benefits 
(e  g.  lower  risk,  shorter  schedule,  lower  costs)  that  could  outweigh  their  disadvantages.  These  should  be 
presented  on  their  merits  so  that  an  integrated  assessment  can  be  made  on  which  concepts  should  be 
pursued  further. 

The  information  needed  to  prepare  the  SEMS  (BIks  D60  &  D68)  for  each  altemative  should  also  be 
largely  developed  along  with  examples  of  the  entry  and  exit  criteria  that  would  be  used  at  key  program 
events.  The  technologies  must  also  be  sufficiently  defined  so  analysts  can  reliably  predict  the 
conceptual  systems  performance  including  performance  while  in  a  test  phase  and  an  operational  support 
phase.  The  manufacturing  technologies  needed  and  the  impact  of  the  technologies  embedded  in  the 
conceptual  "system"  on  manufacturing  processes  and  productivity  must  be  defined  so  they  can  be 
implemented  according  to  the  established  schedule. 

The  definition  of  the  akemative  systems  must  be  developed  with  enough  details  so  they  are  adequate  to 
support  preparation  of  the  Cost  Analysis  Requirements  Description  (CARD)  in  BR<s  D  52  and  D  72  which 
must,  in  turn,  support  esttmatii^g  the  program  costs  and  making  a  Milestone  I  decision.  This  cost 
estimate  must  include  acquisition  cost  (including  breakout  of  development  and  production  costs), 
operation  and  suport  (O&S)  costs,  and  a  life  cycle  cost  (LCC)  estimate  summary.  Cost  estimates  would 
be  primarily  parametric  with  analogy  cost  estimating  methods  used  as  a  secondary  technique.  The 
techrx>logies  that  must  be  errployed  or  will  be  employed  to  support  the  system  concept  are  also  to  be 
identified  in  sufficient  detail  that  the  cost  of  the  most  probable  design  implementations  can  be 
parametrically  costed  and  scheduled  for  development,  production,  and  deployment. 

Risk  management  efforts  will  continue  throughout  the  activity  in  this  block.  Earlier  efforts  have 
performed  a  risk  assessment  to  identify  the  key  areas  or  items  that  represent  risk  to  the  program.  The 
risk  management  effort  will  need  to  include  a  risk  analysis  effort  to  establish  the  levels  of  risk  associated 
with  the  subsystems  and  major  components  of  the  preferred  aitemative(s).  The  assessments  or  updates 
to  the  assessments  must  identify  the  key  risk  areas  associated  with  both  products  and  processes  that 
make  up  the  altemative  system(s).  Those  items/elements  that  have  moderate  or  high  risk  ratings  must 
be  managed  so  that  unfavorable  outcomes  do  not  jeopardize  the  entire  program,  (e.g.  alternatives 
approache  are  defined). 
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The  technical  requirements  tor  the  concepts  will  be  stated  in  a  systems  requirements  document  (SRD). 
The  SRO  is  a  predec^sor  to  a  system  specification.  It  is  a  rtonbinding  contractual  document  and  has  a 
format  similar  to  a  system  sp^ification.  The  SRO  contains  Se<^ions  1  through  3  from  a  system 
specification  format,  but  Se^ion  4  type  verifications  would  typically  be  irK:luded  as  part  of  the 
contractor(s)  demonstration/validation  proposals. 

Execution  of  the  Systems  Engineering  Process  (Ref  Mil  Hdbk  499-3)  to  Support  Concef^  Definition;  This 
part  of  the  description  will  be  used  to  describe  the  systems  enoineerinQ  process  tasks  as  identified  in  MU 
Std  and  My  Hdbk  499.  If  vou  are  familiar  wrth  the  content  of  these  docunwnts  vou  mav  want  to  skip  over 
the  remainder  of  the  description.  The  systems  engineering  process  of  functional  analysis,  synthesis,  and 
balance  and  control  (e.g.  trade  off  analyses)  is  used  to  translate  and  allocate  the  operational 
requirements  into  technical  requirements  for  each  major  element  of  the  corrceptual  'system."  The 
process  also  supports  interface  identifications  between  the  major  elements,  arid  estimates  of  the 
technical  budgets  fc'  the  work  required  to  complete  the  development .  production,  deployment  and  life 
cycle  sustainment  of  each  alternative  concept.  Systems  functions  relating  operational  requirements  to 
design  solutions  (alternative  cortcepts)  are  updated/developed  from  previous  study  activities  and 
evaluated  through  a  process  known  as  system  requirements  analysis.  The  alternative  concepts  under 
consideration  continue  to  be  described  in  greater  detail,  commensurate  with  the  level  of  definition  of  the 
system  functions  and  evaluated  for  their  suitability  (effectiveness)  through  conceptual  design  studies 
(design  synthesis).  The  interrelationship  between  the  needs,  operational  requirements  and  technical 
characteristics  (system  requirements)  evaluated  in  the  various  concepts  are  compared  against  pre- 
established  measures  of  merit  and  technical  (performance)  parameters  to  assess  the  effectiveness  of  the 
concepts  under  consideration  and  provide  insight  into  additional  study  opportunities,  technology 
requirements  and  risks  (balance  and  control).  The  following  discussion  d^ribes  the  three  major 
components  of  the  activity  which  contribute  to  the  refinement  of  system  and  subsystem  requirements 
and  definition  of  viable  alternative  concepts  for  the  preferred  alternatives  review  and  use  during  the 
requirements  summit. 

(1)  Requirements  Analysis:  The  focus  of  the  requirements  analysis  conducted  during 
concept  definition  is  on  identifying  and  defining  functions  (functional  requirements)  associated  with 
operational  requirements  and  allocating  those  functions  to  system  and  subsystem/major  component 
level  technical  characteristics.  Requirements  analysis  can  be  viewed  as  a  two  step  process  aimed  at 
relating  operational  requirements  to  viable  design  concepts  (descrtoed  in  a  work  breakdown  structure) 
via  system  furx^ional  descriptions  (represented  in  a  functional  architecture).  The  requirements  analysis 
activity  serves  as  the  principle  link  between  the  operational  command  activities  (mission  need  statement 
preparation  and  operational  requirements  definition)  and  the  developer's  task  of  identifying  and 
evaluating  viable  conceptual  design  solutions.  The  process  of  generating  the  system  requirements  is 
highly  interactive  with  the  development  of  operational  requirements;  definition  of  each  is  influenced  by 
the  analyses  conducted  in  the  conceptual  design  and  balance  &  control  activities.  A  variety  of  analytical 
methods  and  concepts  are  applied  in  identifying  and  allocating  functions  to  lower  levels  and 
consequently  defining  system  technical  characteristics  more  precisely. 

(a)  Functional  analysis  and  allocation  is  a  principle  component  of  requirements 
analysis  and  involves  the  identification  of  top  level  functions  and  subfunctions  meeting  stated  operational 
requirements,  typically  for  a  variety  of  alternative  concepts.  Functional  Flow  Block  Diagrams  (FFBDs) 
are  used  to  denxmstrate  the  interrelationships  of  each  function  and  associated  subfunctions  with  one 
another  and  the  system.  Time  Line  Sheets  (TLSs)  are  used  to  represent  functional  sequencing  and  time 
critical  relationships.  These  can  be  derived  based  on  specific  times  established  in  operational 
requirements  documents  for  accomplishing  a  discrete  task,  a  part  of  a  mission  or  perhaps  an  emergency 
procedure.  The  process  of  defining  functions  at  lower  levels  of  detail  is  accomplished  by  the 
Requirements  Allocation  Sheet  (RAS)  which  has  three  principle  purposes: 

-  to  record  performance  requirements  established  tor  each  function 

-  during  synthesis,  to  show  the  allocation  of  functional  requirements  to 
inckvidual  system  elements  or  combinations  of  elements  and 
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-  to  derive  the  functionalty  oriented  data  used  in  describing  the  system. 
An  output  of  the  process  that  identifies  multipte  levels  of  functions  (requirements  allocation)  and  their 
relationships  is  commonly  referred  to  as  the  functional  architecture.  The  furrctional  architecture  is  useful 
for  identifying/refining  design  concepts  and  serves  as  a  baseline  for  assessing  functional  and  for 
conducting  trades  on  performance  (function,  cost,  schedule,  risk),  for  assessing  the  feasibility  of 
achieving  the  requirements  and  establishing/confirming  the  validity  of  each  design. 


(2)  Conceptual  Design  (Synthesis):  The  synthesis  activity  produces  conceptual  designs 
to  implement  evolving  functional  architectures  and  provides  information  for  evaluating  the  capability  of 
those  designs  to  satisfy  evolving  system  requirements  (contained  in  the  SRD)  and  operational 
requirements  (contained  in  the  ORO).  The  concept  definition  will  address  the  total  system  (system 
elements)  in  the  context  of  the  life  cycle  phases  and  develop  the  alternative  designs  to  the  specified 
level  of  detail  to  support; 

(a)  cost  schedule  and  performance  evaluations. 

(b)  implementation  of  a  risk  management  plan  (risk  identification,  evaluation 

and  control), 

(c)  identification  of  critical  technology  requirements  (including  products, 
processes  and  materials). 

Two  widely  used  tools  to  accomplish  the  synthesis  of  design  concepts  are  the  Concept  Description  Sheet 
(CDS)  and  the  Schematic  Block  Diagram  (SBD).  The  CDS  is  used  to  collect  performance  requirements 
and  constraints  (identified  in  functional  analysis)  and  describe  technical  characteristics  that  satisfy  those 
requirements.  It  conveys  a  gross  level  of  design  demonstrating  compliance  with  the  allocated 
requirements,  time  line  sheets  and  the  functional  flow  block  diagram.  The  SBD  serves  as  the  basis  for 
models  of  the  evolving  system  and: 

(d)  depicts  a  complete  response  to  the  functional  requirements, 

(e)  depicts  compatibility  between  elements  of  the  system  and  interfacing 

systems/subsystems 

(f)  provides  traceability  between  system  elements  and  their  functional  origin  and 

(g)  provides  a  mechanism  for  complete  and  comprehensive  change  control,  (i.e. 
the  SBD  can  be  used  during  this  block  activity  to  develop  the  Interface  Control  Documents,  ICDs)  for 
each  design  concept. 

(h)  functions  that  are  not  well  defined  and/or  cannot  be  completely  described  by 
physical  models  are  identified  for  further  evaluation. 


(3)  Balance  &  Control  describes  the  set  of  activities  associated  with  evaluating  the 
derived  system  requirements,  assessing  the  performance  of  the  alternative  design  concepts  under 
consideration  and  formulating  recommendations  regarding  the  nx>st  promising  alternatives.  This 
evaluation  and  decision  activity  is  supported  through  trade  studies  (trade-off  analyses)  and  deals  with 
issues  pertaining  to  risk  management,  configuration  management,  technology  programs  and  plans, 
manufacturing  technologies,  environmental  management  and  performance-based  progress 
measurement  activities.  The  analyses  accomplished  at  this  point  in  the  process  also  identify  alternatives 
that  represent  less  than  100%  solutions  and  the  degree  of  shortfalls. 

(a)  Trade  studies  are  conducted  on  each  alternative  to  establish  functional 
requirements  and  technical  characteristics,  evaluate  the  resulting  functional  architectures,  examine 
alternative  technology  strategies  and  risk  abatement  approaches,  and  evaluate  gross  levels  of  design  to 
support  identification  of  preferred  products  and  processes. 

(b)  Risk  management  activities  include  identifying  and  quantifying  technical  risk 
in  terms  of  cost,  schedule  and  performance  for  each  alternative  concert  under  study.  Technology 
application  risks  (products  and  processes)  are  identified  and  quantified  at  a  level  commensurate  with  the 
level  of  detail  for  each  concept  under  consideration.  The  risks  associated  with  interface  characteristics 
of  the  functional  architecture  (both  internal  and  external)  are  also  quantified.  Risk  control  plans  are 


Nov  93 


■r- 


deveioped/updated  as  the  desigr^  are  iterated  and  include  strategies  and  concept  specific  risk 
abatement  activities.  This  information  is  used  as  a  part  of  the  activity  described  in  para  7.c. 

(c)  Configuration  management  activities  include  developing  preliminary 
configuration  and  data  management  plans  and  supporting  continuing  development  of  the  System 
Requirements  Document  (SRD)  and  Baseline  Concept  Descriptions  (BCDs).  In  support  of  follow-on 
concept  definition  activity  (element  D37B),  system  characteristics  will  evolve  sufficiently  to  warrant 
creation  of  Interface  Control  Working  Groups  (ICWGs)  for  coordinating  systems  engineering  activities 
across  system  and  subsystem  interfaces. 

(d)  The  concept  definition  work  requires  the  team  to  continue  assessing  existing 
technology  capabilities  for  their  potential  application  to  the  evolving  systems  and  identifying  the  critical 
technology  shortfalls.  Continuous  technical  interchange  between  the  project  cadre  and  laboratories  and 
industry  offering  enabling  technologies  are  necessary  in  order  to  assess  the  viability  of  some  of  the  high 
risk  concepts  being  explored  and  provide  guidance  regarding  potential  future  technology  investments. 

Element  D43.  Assess  Technology  Needs  transforms  system  requirements  judged  to  be  unachievable 
with  current  technologies  and  characterizes  those  deficiencies  in  terms  of  technology  needs  for 
investment  by  the  laboratories.  Those  technologies  that  show  significant  promise  and  achieve  the 
needed  capabilities  could  then  be  inserted  at  an  appropriate  phase. 

(e)  Manufacturing  Capabilities  Rec^irements  (MCR)  is  a  process  (tool)  used  to 
identify  acxf  evaluate  manufacturirig  technologies,  product  and  process  characteristics  and  industrial 
base  capabilities  deemed  necessary  for  system  development  and  support.  This  assessment  reviews  in 
detail,  each  alternative  concept  under  consideration  ar^  evaluates  the  impact  from  materials, 
components,  tooling  artd  equipment  and  processing  techniques.  The  MCR  assessment  serves  as  basis 
for  developing  program  manufacturing  strategy  and  and  risk  reduction  approaches:  these  are  updated  as 
the  program  and  concepts  mature. 

(f)  Environmental  Management  is  evolving  as  a  major  consideration  for  weapon  •  ® 

system  acquisition  arxf  requires  the  development  of  an  environmental  management  strategy  and  plans. 

Standards  for  the  use  of  hazardous  materials  and  pollutants  continue  to  be  tightened  and  represent  a 

major  design  consideration  affecting  system  performance  throughout  its  life  cycle.  Alternative  design 

concepts  and  the  driving  system  characteristics  must  be  evaluated  against  existing  and  projected 

environmental  standards  early  to  address  design,  development,  testing,  deployment,  and  supportability 

challenges  posed  by  these  standards.  • 

(g)  Refinement  of  the  Logistics  Support  Analysis  Strategy  (LSAS)  and 
preparation  of  the  Logistic  Support  Analysis  Plan  serves  as  a  basis  for  assessing  supportability, 
operability,  and  maintainability  during  concept  definition.  Principle  outputs  identified  in  the  strategy 
include  support  objectives,  goals,  thresholds,  design  and  support  criteria,  support  corrcepts  (logistics  tail) 

and  target  improvements  over  existing  systems.  The  LSA  plan  will  be  a  dynamic  document  that  identifies  • 

the  tasks,  candidate  lists  of  subsystems/major  components  needing  LSA  review,  the  management 
structure  and  authority  levels  and  feedback  arxf  control  procedures. 

(h)  For  each  alternative  concept  under  consideration,  technology  assessments 
are  conducted  to  identify  critical  technologies  to  the  level  of  definition  of  each  concept.  These  critical 

technologies  are  evaluated  against  what  is  currently  available  or  projected  to  be  available.  Shortfalls  are  - 

identified  as  technology  needs  for  potential  addition  to  government  laboratories  and  industrial  base 

research  and  development  activities.  This  activity  requires  a  sustained  interface  between  the  project 

team,  government  laboratories,  product  centers  (across  all  services),  and  industry  and  includes  a 

consideration  for  Non-developmerrtal  Items  (BIk  D41)  and  Cooperative  Devebpment  Programs  (BIk 

D42). 

(i)  Effectiveness  analysis  is  a  principle  element  of  the  balance  and  control 

activity,  providing  qualitative  and  quantitative  ratings  on  the  performance  of  the  alternative  concepts  * 

urxfer  consideration.  Predetermined  performance  metrics,  referred  to  as  Measures  Of  Effectiveness 
(MOEs)  serve  as  benchmarks  against  which  alternative  concepts  operational  capabilities  are  appraised. 
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Potential  sources  of  inputs  for  developing  MOEs  for  use  in  the  evaluation  activity  include  selection 
criteria  employed  during  Pre-Milestone  0  concept  studies  and  analysis,  the  Mission  Need  Statement. 
Milestone  0  decision  documentation  (including  Acquisition  Decision  Memorandum,  ADM  and  Program 
Management  Directive,  PMD)  and  the  concept  exploration  studies  performed  previously.  The  locus  is  on 
the  total  system  (equipment,  facilities,  personnel,  data,  and  software)  and  effectiveness  is  assessed 
throughout  the  life  cycle  (development,  manufacturing,  verification,  deployment,  operations,  support, 
training,  and  disposal  phases).  Subsequent  iterations  through  requirements  analyses  and  design 
synthesis  are  driven  by  the  results  of  the  effectiveness  analysis. 

(j)  Performance  based  progress  management  describes  the  underlying 
philosophy  for  the  contemporary  systems  engineering  process  and  involves  the  development  and 
application  of  event  driven  milestones.  This  is  a  major  consideration  during  balance  and  control 
activities  and  provides  specific  exit  criteria  for  concept  exploration  studies.  Updates  to  the  Systems 
Engineering  Management  Plan  (SEMP)  and  Systems  Engineering  Master  Schedule  (SEMS)  are 
accomplished  as  a  part  of  the  balance  and  control  activities.  Specific  criteria  developed  and 
documented  in  the  SEMS  is  used  as  a  basis  for  determining  when  each  design  concept  has  been  defined 
to  the  necessary  level  of  detail  and  characterizes  the  performance  of  each  corrcept  as  measured  by 
predetermined  Technical  Parameters  (TPs)  evaluated  on  a  continuing  basis  through  Technical 
Performance  Measurement  (TPM).  Technical  parameters  are  a  select  set  of  system  technical  metrics 
chosen  by  management  to  track  development  progress;  TPs  are  identified  through  and  support  risk 
analyses,  contract  specifications,  and  contracting  strategy.  The  process  of  continuously  assessing  the 
degree  of  anticipated  and  actual  achievement  of  TPs  is  referred  to  as  TPM.  Technical  performance 
measurement  provides  insight  into  design  deficiencies  and  provides  an  indication  of  the  potential  impact 
on  system  level  requirements.  The  TPM  process  provides;  1)  visibility  into  actual  versus  planned 
performance.  2)  early  detection  or  prediction  of  problems  which  require  management  attention,  and  3) 
assessment  of  the  program  impact  resulting  from  proposed  change  alternatives. 

(k)  The  trade  study  activities  culminate  in  the  publication  of  Trade  Study 
Reports  (TSRs)  which  identify  and  characterize  promising  concepts,  document  the  results  of  significant 
trades,  identify  study  assumptions  and  constraints,  provide  an  assessment  of  concept  risks  and  methods 
of  abatement  and  document  rationale  used  in  the  decision  process. 


8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  alternatives  to  be  defined  have  been  selected  by  the  operating  command  (BIk 
C  25)  and  the  Concept  Exploration  (BIk  D  37)  activity  has  been  completed. 

b.  Exit; 


(1)  The  concepts  have  been  defined  so  that  the  decision  makers  in  the  operating  and 
implementing  MAJCOMs  can  review  these  more  detailed  definition(s)  and  can  decide  which  of  the 
alternative  conepts  would  best  meet  the  needs  and  could  be  pursu^  in  the  demonstration/validation 
phase. 

(2)  Concept  definition  is  concluded  once  it  has  been  established  that  the  project 
milestones  identified  in  the  SEMS  have  been  met,  that  all  technical  plans  have  been  updated  (including 
the  SEMS)  and  they  support  the  SEMP. 

(3)  The  concepts  must  be  adequately  defined  to  support  the  cost  estimates  that  have  to 
be  prepared  and  submitted  as  part  of  the  program  documentation  and  to  support  the  Milestone  I  decision 
process. 

(4)  The  risks  associated  with  the  concept(s)  and  risk  management  methods  to  be  used 
must  be  describe  and  implemented. 

(5)  The  poterrtial  environmental  impact  associated  with  developing,  producing, 
operating,  and  maintaining  the  products  using  the  planned  processes  must  be  clearly  identified. 
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9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs; 

(1)  MAJCOM  Selected  Preferred  Alternatives  (C25) 

(2)  System  Concept  Defined  to  WBS  LvI  2 

(3)  COEA I  Plan  (D23) 

(4)  Mission  Need  Statement  (D49) 

(5)  Draft  Operational  Requirements  Document  (Cl  9) 

(6)  Systems  Requirements  Document  (D37) 

(7)  Identify  Non  Developmental  Item  Candidates  for  System  Concepts  (D41 ) 

(8)  Identify  Items  for  Joint  Use/Coopreative  Development  (D  42) 

(9)  Draft  arKl  Final  Request  for  Proposal  (Review  Comments)  (D64) 

(10)  Functional  Plans  (e  g.  SEMP,  SEMS.ILSP.etc.)  (60) 

(11)  Assessments  of  Advanced  Techrwlogy  for  Transition  (D30) 

(12)  Baseline  Concept  Descriptions  to  a  WBS  Level  2  (D37) 

(13)  Source  data  for  CARD  preparation  (  D49,  D48.  and  C23) 

(14)  Comparative  Analysis  of  Preferred  Alternatives  (D48&  D46) 

b.  Outputs: 

(1)  Preferred  Coruepts  Defined  (To  WBS  Level  3)  (D45B) 

(2)  Updated  Systems  Requirements  Document  (SRD)  (D45B) 

(3)  Update  to  the  Database  (D73) 

(4)  Technical  Information  for  the  CARD  (D52  &  D72) 

(5)  Updated  Baseline  Concept  Descriptions  (D45B) 

(6)  Programmatic  and  Tech  Info  (D50,  D51,  D53,  D54  &  D71) 

(7)  Define  Adv  Technology  Needed  for  Transition  &  Integration  (D30) 

(8)  Identify  Non  Developmental  Items  in  Systems  &  Subsystems  (D41 ) 

(9)  Identify  Cooperative  Development/Joint  Use  Opportunities  (D42) 

(10)  Technical  and  Programmatic  Information  for  RFP  Preparation  (D64) 

(11)  Identify  Manufacturing  Capability  Requirements  (D45B,  D60  &  D68)) 

(12)  Source  data  for  Draft  and  Final  MS  1  Documents  and  Functional  Plans  (D60  &  D68) 

(13)  Concept  Risk  Assessment  (D45B,D60,  &  D68) 

(14)  Trade  Studies  Report  (D45B  &  C19) 

(15)  Effectiveness  Analysis  Info/Update  the  COEA  I  Analysis  &  Report  (C23) 

(16)  Supportability  Analyses  (D45B) 

(17)  SurvivabilityA/ulnerability  Analyses  (D45B) 

10.  KEY  REFERENCES: 

a.  Defense  Systems  Management  College-  Systems  Engineering  Management  Guide,  Jan  90. 

b.  DODI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb  91 . 

c.  DODI  5000.2-M,  Defense  Acquisition  Management  Documentation  and  Reports,  Feb  91 . 

d.  MIL-STD-499B,  Systems  Engineering. 

e.  MIL-HDBK-499-3,  Systems  Engineering/C^nfiguration  Management  Life  Cycle  Application 
(Draft),  Dec  92. 

f.  DODD  5000.1 ,  Defense  Acquisition,  23  Feb  91 . 

g.  DODD  5000.4,  OSD  Cost  Analysis  Improvement  Group  (CAIG),  24  Nov  92. 
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11.  IMPLEMENTATION  TOOLS:  Several  tools  are  identified  in  Para.  7  for  accomplishing  the  tasks  in 
this  element.  A  summary  of  these  tools  are  listed  here  along  with  a  brief  description  of  their  use: 

a.  Cor)cept  Design  Sheet;  Used  to  collect  performance  requirements  and  constraints  (identified 
in  functional  analysis)  and  describe  technical  approaches  for  satisfying  those  requirements. 

b.  Functional  Architecture:  Process  of  arranging  functions/subfunctions  in  a  hierarchy,  showing 
internal  and  external  functional  and  physical  interfaces. 

c.  Functional  Flow  Block  Diagram:  Layered  matrices  showing  the  sequential  interface 
relationships  for  the  functions  in  a  system. 

d.  Interface  Control  Document;  A  document  that  describes  system/subsystem  interface  design 
implementation  of  the  requirements.  The  ICD  is  a  repository  for  interface  definition  data  (including 
drawings,  sketches,  functional  lists,  procedures  and  processes,  equations,  etc.)  for  use  in  designing  the 
interface. 

e.  N  Squared  Diagrams:  Matrix  used  to  kJentify/summarize  the  interaction  of  functional  data 
interfaces  and  system  inputs  and  outputs. 

f.  Schematic  Block  Diagram;  Used  as  the  basis  for  models  of  the  evolving  system;  this  tool: 

(1)  depicts  a  complete  response  to  the  functional  need. 

(2)  depicts  compatibility  between  elements  of  the  system  and  interfacing 
system/subsystems. 

(3)  provides  traceabilKy  between  system  elements  and  their  furxnional  origin  and 

(4)  provides  a  mechanism  for  complete  and  comprehensive  change  control,  (i.e.  SBD  is 
used  to  develop  the  ICDs)  for  each  design  corx:ept. 

g.  Systems  Engineering  Management  Plan:  A  comprehensive  document  that  describes  how  the 
fully  integrated  engineering  effort  wilt  be  managed  and  conducted. 

h.  Systems  Engineering  Master  Schedule:  A  compilation  of  key  accomplishments  requiring 
successful  completion  to  pass  identified  events.  Accomplishments  include  major  and  critical  tasks, 
activities  and  demonstrations,  with  associated  criteria. 

i.  Technical  Performance  Measures:  A  select  set  of  critical  system  technical  metrics  tracked  for 
verification  of  the  degree  of  anticipated  versus  actual  achievement. 

j.  Time  Line  Sheets;  Tabular  data  summarizing  projected/actual  times  for  accomplishing  related 
and/or  interactive  tasks. 

12.  PLANNING  GUIDANCE:  Prior  to  initiating  this  activity,  predecessor  program  development  activities 
judged  to  be  of  similar  scope  should  be  investigated  for  lessons  learned,  best  practices,  resource 
requirements  and  duration.  This  information  should  be  included  in  program  planning  activity  including 
development/update  of  the  Systems  Engineering  Management  Plan  and  Systems  Engineering  Master 
Schedule  supporting  this  activity  and  follow-on  activities  in  this  phase. 

a.  DURATION:  The  duration  of  the  concept  definition  activity  is  a  furx^tion  of  the  scope  of  the 
need,  the  complexity  of  the  system  and  subsystem  characteristics  (functions  and  requirements)  arxJ  the 
number  of  preferred  concepts  that  require  further  definition.  Concept  definition  could  take  from  several 
months  (smaH  number  of  preferred  alternatives  to  a  simple  operational  requirement  and  need)  to  one 
and  a  half  to  two  years  (for  a  complex  set  of  requirements  involving  several  preferred  alternatives). 


NovM 


b.  CMSTRAIIfrS:  Time  and  program  funds  are  predictable  constrsunts  that  will  bound  the 
concept  definition  activities.  Inadequate  defirtition  of  operatiorral  requirements,  poorty 
planned/documented  prograrnmatic/tecfmical  approach  wHI  complicate  the  work  effort  and  adversely 
impact  schedule  and  the  quality  of  the  results.  The  proper  resources  in  the  right  numbers  must  be 
identified  and  avadabie  to  support  the  effort. 

c.  RESOURCES:  The  size  and  functional  makeup  of  the  staff  assigned  to  this  activity  will  vary 
depending  upon  the  system  requirements  (technical  and  programmatic).  The  use  of  personnel  with  prior 
experience  in  the  analyses  conducted  during  Pre-Milestone  0  activities  should  facilitate  the  transition  of 
the  project  through  Milestone  0  and  enhance  the  quality  of  the  product  of  the  concept  definition  effort. 

d.  LESSONS  LEARNED:  The  Air  Force  Lessons  Learned  Database  may  be  consulted  via 
Automated  Lessons  Learned  Capture  and  Retrieval  System  (ALLCARS).  At  the  time  this  data  sheet  was 
drafted,  no  lessons  learned  pertaining  to  conducting  concept  definition  was  available. 

e.  BEST  PRACTICES:  The  concept  definition  activity  must  be  approached  in  a  systematic  aixJ 
disciplined  manner  to  ensure  that  the  soultions  are  adequately  defined  to  establish  if  they  would  satisfy 
the  funtbnal  and  operational  requirements  and  ultimately,  mission  needs. 

(1)  Design; 

(a)  Measurable  design  parameters  must  be  established. 

(b)  System  requirements  are  specified  and  allocated  based  on  function. 

(c)  All  relevant  system  requirements  are  properly  flowed  down. 

(2)  Trade  Studies; 

(a)  Trade  studies  should  be  iterative. 

(b)  Technology  needs  for  each  aitemative  solution  must  be  clearly  identified 
and  program  cost,  and  schedule  risk  associated  with  these  deficiencies  must  be  realistically 
characterized. 

(c)  Development,  producibility,  deployability,  operability,  supportability  and 
reliability  should  be  consider.  The  focus  of  trade  studies  is  on  quantifying  cost,  schedule  and 
performance. 
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(3)  Planning/Implementation; 

(a)  The  programmatic  and  technical  objectives  of  concept  definition  are  clearly 
defined  and  documented  prior  to  corKlucting  the  studies. 

(b)  Proven  techniques  (tools)  are  employed  in  a  disciplined  manner  when  * 

conducting  concept  definition. 

(c)  Evaluation  results,  assumptions  arxf  constraints  must  be  documented  in  a 
formal  data  base  for  future  use. 

(d)  Event  based  milestones,  clearly  defined  success  criteria  and  (baseline) 
technical  performance  measures  should  be  employed. 

f.  TRAPS: 

(1)  Poor  definition  of  acceptance  or  success  criteria  for  event  based  scheduling. 

(2)  Lack  of  a  common  set  of  program  priorities  across  functionals.  PCs.  ALCs  &  the  operating 
command. 

(3)  Alternatives  not  sufficiently  robust  to  effectively  perform  other  missions  or  tasks.  • 

(4)  Too  little  attention  to  "off  design"  performance  and  operating  characteristics  of  the  system. 
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1.  ELEMENT:  D41.  TBS  12.4.2  (IFC  93-3) 

2.  ELEiKNT  TITLE:  Define  Use  of  Non-Devetopmental  Herns  (NDI) 
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3.  ELEMENT  OWNER(S):  The  Office  of  the  Assistant  Secretary  of  Defense  for  Production  and 
Logistics  (OASD  (P&L)  SDM)  is  charged  with  overseeing  DoD  activHy  as  it  relates  to  NDI  procurement. 

4.  ELEMENT  STAKEHOLDER(S):  Developing  Protect  Office,  Operating  Command,  Air  Force 
Competition  Advocate,  and  The  Deputy  Under  Secretary  of  Defense  for  Acquisition  Reform 
(OSD/DUSD(AR)). 

5.  REQUIREMENT: 

a.  DODI  Directive  5000.1  „  Deferrse  Acquisition,  Part  1 .  Part  1 ,  page  4,  Para  1  .c,  23  Feb  91 . 
states  maximum  practicable  use  shall  be  made  of  commercial  and  other  non-developmental  items.  In 
describing  these  items,  maximum  practicable  use  shall  be  made  of  notvgovemment  standards  and 
commercial  item  descriptions. 

b.  DODI  5000.2,  Defense  Acquisition  ManagemerH  Policies  and  Procedures,  Part  6,  Section  L; 
Part  6,  Section  H,  para  3.a.(3);  Part  3,  page  3-1 1 ;  and  Part  10,  Section  C,  para  2.d,  Non-Developmental 
Hems,  23  Feb  91 .  states  policies  and  procedures  which  establish  the  basis  for  cost-effective  use  of 
commercial  products  and  other  non-developmental  Hems  in  defense  systems  and  equipment. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  element  is  to  define  purchasing/using  existing  products  or 
systems  rather  than  pursuing  development  of  new  Hems. 

b.  Objectives:  Define  existing  or  emerging  products/technology  that  has  potential  to  save  life 
cycle  cost  given  the  requirements  and  updated  information  at  this  program  stage.  The  following 
objectives  can  be  used  to  analyze  potential  products/lechnology: 

(1)  Reduced  developmental  cost 

(2)  More  rapid  fielding 

(3)  Proven  capabilHy/reliabilHy 

(4)  Increased  competHion 

(5)  Established  logistics  support 

(6)  Tech  data  developed 

(7)  The  Hem  is  likely  state-of-the-art 

(8)  CompetHive  Forces  have  shaped  Hs  functionalHy 

(9)  Existing  established  market 

(10)  Reduced  risk 


7.  DESCRIPTION: 


a.  This  is  an  update  to  the  work  which  went  on  in  D13  and  D27  on  non-developmental  Hems. 
The  brief  NDI  outline  accomplished  in  (D13)  and  Hs  further  exploration  (D27)  are  updated  to  reflect 
changes  in  the  program  including  requirements  arxj  threat  assessment. 

b.  At  this  stage,  we  are  trying  to  narrow  the  amount  of  concepts  and  aHematives  from  (D37B 
and  D29).  The  Air  Force  will  investigate  off-the-shelf  Hems  and  will  evaluate  them  for  satisfying  Air 
Force  needs  (D29). 
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8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  A  material  need  has  been  identified  and  options  are  formulated.  Also  preMminary 
performance  ranges,  thresholds,  and  trade-offs  associated  with  what  is  Imown  about  NDI  at  this  point  of 
the  project. 

b.  Exit:  Update  NOI  information  using  COEA  and  threat  assessment  studies.  Also,  update  the 
preliminary  investigation  of  alternative  logistics  support. 

9.  KEY  l»tf>UTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  The  project  team  requires  a  description  of  the  mission  need  from  the  MNS  summary, 
COEA,  and  Threat  assessment. 

(2)  Results  from  market  surveillance  of  laboratories  and  the  industrial  base  through 
trade  shows  arxj  trade  magazirres  is  the  primary  method  for  gaining  knowledge  of  existing  technology 
and  products  (D29).  An  updated  cost  effective  analysis  should  be  performed  on  the  item  to  find  if  it  is  a 
viable  solution  to  the  item  needed. 

b.  Outputs:  Provide  the  Operating  Command  with  insight  to  potential  concept  alternatives  that 
address  his  draft  mission  need  (D37).  It  is  important  that  selected  NDI  alternatives  flow  back  into  this 
element  so  they  can  be  integrated  in  a  realistic  need. 

10.  KEY  REFERENCES: 

a.  Title  10  U.S.C.  2325,  Preference  for  Non-developmental  Items,  18  Oct  87.  This  section  of  Title 
10  mostly  describes  Congressional  mandate  to  the  Air  Force  to  look  at  and  use  NDI  in  a  weapon  system 
whenever  possible. 

b.  Proposed  Strategic  Plan  to  Pi  le  Acquisition  Reform,  8  Jun  93.  Contains  draft  information  on 
using  NDI  as  a  preferred  alternative  *«  eveloping  new  systems  and  establishing  a  group  of  advisors 
from  OSD/DUSD(AR)  to  help  in  NDI  p«  curement. 

11.  IMPLEMENTATION  TOOLS: 

a.  Trade  magazines  and  trade  shows  for  market  surveillance. 

b.  Buying  NDI/SD-2,  Oct  90.  Contact  Office  of  the  Assistant  Secretary  of  Defense  (Production 
and  Logistics),  Washington,  D.C.  20301-8000.  This  tool  mainly  describes  the  buying  process  for  NDI. 

c.  Market  Analysis  for  Non-Developmental  Items,  SD-5.  Contact  Office  of  the  Assistant 
S)<H;retary  of  Defense  (Production  and  Logistics),  Washington,  D.C.  20301-8000.  Describes  NDI  as  an 
e.  c«llent  alternative  to  business  as  usual. 

d.  Joint  Command  Commercial  Off-the-Shelf  (COTS)  Supportability  Working  Graup  (CSWG) 
Final  Report.  Jun  91 .  Contact  ASC/SDC.  Describes  the  life  cycle  concerns  of  NDI.  This  is  an  excellent 
guide  and  is  highly  recommended  to  anyone  who  is  considering  the  use  of  NDI. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  You  should  start  with  the  Mission  Need  Statement  (MNS)  and  the  Government 
Systems  Requirement  Analysis  to  get  a  handle  on  the  architecture/configuration  alternatives.  This  is  an 
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ongoing  process  throufl^KXJt  Pre-Milestone  0  to  Milestone  I  and  will  vary  in  duration  depending  on 
complexity  of  Hem  and  length  of  milestone. 

b.  CONSTRAINTS:  As  always,  timing  is  an  major  constraint.  If  a  NDI  is  selected  early,  it  may 
become  obsolete  and  out  of  production  by  the  time  the  weapon  system  is  fielded.  You  have  limited  data 
rights  with  NDI.  no  configuration  control,  and  no  existing  AF  supp^  structure. 

c.  RESOURCES:  All  functional  areas  need  to  be  involved  in  NDI.  Much  of  their  involvement 
will  be  in  the  requirements  area.  There  will  be  a  low  level  of  man-hours  with  NDI  at  this  stage  of  the 
project.  Most  of  the  man-hours  will  be  put  into  the  very  important  requirements  area  so  that  realistic 
requirements  levels  will  be  defined  and  a  better  selection  of  NDI  wHt  be  made. 

d.  LESSONS  LEARNED:  There  were  7  lessons  teamed  in  the  Automated  Lessons  Learned 
Capture  and  Retrieval  System  (ALLCARS)  database.  The  numbers  are  1449. 20009, 20012, 20016, 
20045,  20047,  20084.  These  items  all  dealt  with  logistical  support  problems  and  proems  with  sHghtly 
modified  NDI  items.  Therefore,  pay  special  attention  to  these  areas  when  considering  NDI. 

e.  BEST  PRACTICES:  If  NDI  is  not  considered  at  the  early  stages  of  the  acquisition  cycle, 
then  you  probably  will  not  be  able  to  acquire  it  as  an  NDI  item  later. 

f.  TRAPS  Not  taking  the  follow-on  support  and  possible  added  life  cycle  costs  into  account 
when  using  NDI.  Too  much  modification  usually  negates  any  life  cycle  cost  savings. 
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1.  ELEMENT:  042,  TBS  1 .2.4.3  (IFC93-3) 

2.  ELEMENT  TITLE:  Define  Cooperative  Opportunities  (DCO) 

3.  ELEMENT  OWNER(S):  Deputy  Under  Secretary  of  Defense  (International  Programs)(OUSD(IP)), 
Assistant  Under  Secretary  of  Defense  for  Programs  &  Acquisition  (USDA(P&A)),  SAF/AQXI,  AFMC/IA, 
WUXPI. 

4.  ELEMENT  STAKEHOLOER(S):  Prxiject  Office,  Operating  Command,  Air  Force  Competition 
Advocate. 

5.  REQUIREMENT:  DOOl  5000.2 ,  Defense  Acquis4ion  Management  Documentation  and  Reports,  23 
Feb  91 ,  Part  3,  pg.  3-9,  and  Part  5,  Section  F,  para  3E.  TMs  identifies  the  requirement  to  consider 
poterxial  oooperatrve  research  and  development. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  is  to  update  the  work  acconrpiished  on  cooperative  opportunities  from 
D14  and  D28  with  updated  information.  The  documentsttion  is  compounded  in  Cooperative  Opportunities 
Document  (COD),  and  required  at  Milestone  I  and  beyond  (see  DODI  5(X)0.2  for  detaHs). 

b.  Objective:  To  define  applicable  Cooperative  Development  items  for  the  program.  By 
defining  the  preferred  alternatives  (D37B),  these  preferred  alternatives  can  be  evaluated  for  there 
potential  for  cooperative  development  opjxKtunities  that  could  be  pursued  with  other  services  or  aUied 
nations. 

7.  DESCRIPTION: 

a.  Key  inputs  are  to  define  the  preferred  alternatives  (D37B),  which  is  accomplished  by 
monitoring  industry  and  participating  in  government  programs  through  IR&D,  RFIs,  RFPs,  or  other 
means  (D29)  and  updating  the  requirements  and  specifications.  In  this  area,  DoD's  influence  on  industry 
is  primarily  through  Small  Business  Innovation  Research  (SBIR)  and  Independent  Research  and 
Development  (IR&D)  activities.  DoD  activities  invite  small  business  firms  with  strong  research  and 
development  capabilities  in  science  and  engineering  to  submit  proposals  under  the  SBIR  program.  The 
objectives  of  this  program  include  stimulating  technological  innovation  in  the  private  sector, 
strengthening  the  role  of  small  business  in  meeting  DoD  research  and  development  needs,  fostering  and 
encouraging  participation  by  minority  and  disadvantaged  persons  in  technolo^l  innovation,  and 
increasing  the  commercial  application  of  DoD-supported  research  or  research  and  developm^  results. 
Determining  applicability  of  Non  Developmental  Items  (NDI)  (D41)  is  accomplished  in  a  parallel  time 
frame. 


b.  The  DODI  50(K).2  requirement  for  assessing  DCO  mandates  the  consideration  of  buying 
allied  systems  or  cooperating  between  our  various  allies  on  development,  before  initiation  of  a  new 
acquisition  program.  A  DCO  assessment  is  required  for  Acquisition  Category  (ACAT)  I  programs  and 
cooperative  opportunities  should  be  investigated  as  part  of  the  acquisition  strategy  for  ACAT  II,  III,  and 
IV  programs.  Specifically,  DODI  5000.2  specifies  an  order  of  preference  for  new  programs  as  follows: 

(1)  Use  or  modification  of  an  existing  U.S.  military  system. 

(2)  Use  or  rrxxjification  of  an  existing  commercially  developed  or  Allied  system  that 
fosters  a  non  developmental  acquisition  strategy. 

(3)  A  cooperative  research  and  development  program  with  one  or  more  Allied  nations. 

(4)  A  new  joint  Senrice  development  program. 

(5)  A  new  Service-unique  development  program. 
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c.  Cooperative  Deveiopmeni  must  be  addressed  during  this  stage  the  program  tor 
documentation  tor  writing  the  COO  at  Milestone  I. 

B.  ENTRANCe/EXIT  CRITERIA: 

a.  Entrance:  A  materiel  need  has  been  identified  and  conception  designs  are  being  tormuiated. 

b.  Exit:  Technical  arvj  programmatic  intormatton  about  posstole  CO  opportunities  with  high 
payoff  potential  has  been  provided  to  the  project  team  for  integration  into  the  conceptual  definrtion 
activities. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  inputs: 

1 )  A  deficierx:y  or  technological  opportunity  has  been  validated  (D37B). 

2)  Key  inputs  on  the  flow  chart  are  to  refine  requirements,  develop  more  concept 
details,  and  update  COEA I  analysis  (037B). 

3)  To  monitor  industry  and  participates  in  government  programs  through  IR&D,  RFIs, 
RFPs,  or  other  means  (029).  In  this  area,  OoO's  influence  on  industry  is  primarily  through  SBIR  and 
IR&D  activities.  OoD  activities  invite  small  business  firms  with  strong  research  and  development 
capabilities  in  science  and  engineering  to  submit  proposals  under  the  SBIR  program.  The  objectives  of 
this  program  include  stimulating  techrwtogical  innovation  in  the  private  sector,  strengthening  the  role  of 
small  business  in  meeting  DoO  research  and  development  needs,  fostering  and  encouraging 
participation  by  minority  and  disadvantaged  persons  in  technological  innovation,  and  increasing  the 
commercial  application  of  OoO-supported  research  or  research  and  development  results.  Determine 
Applicability  of  Non  Devetopmental  Items  (NDI)  (041)  is  axxx>mplished  in  a  parallel  time  frame. 

b.  Outputs:  A  formal  list  of  items  for  joint  use/cooperative  development  will  be  prepared  for  the 
systems  /  subsystems  of  the  preferred  alternatives.  Key  flowchart  output  is  D37B.  Provide  the 
Operating  Conrimand  with  insight  to  potential  concept  alternatives,  such  as  DCO,  that  address  his  draft 
mission  need. 

10.  KEY  REFERENCES: 

a.  HQ  AFMC/XT  Letter,  9  Mar  92,  Development  Planning  Relationship  to  International 
Opportunities.  This  shows  how  DCO  is  integrated  into  the  program  life  cycle. 

11.  IMPLEMENTATION  TOOLS:  None  identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  amount  of  time  needed  to  accomplish  this  activity  is  dependent  upon  the 
complexity  of  the  item.  Forty  man-hours  of  the  project  management  team  should  be  more  than  enough 
time. 


b.  CONSTRAINTS: 

(1)  Time  and  money  in  investigaiing  various  alternatives. 

(2)  Lack  of  a  central  location  to  obtain  needed  information  on  existing  and  planned 
military  and  allied  nation  projects. 

c.  RESOURCES:  Not  much  time  is  needed  at  this  point  of  the  program.  Forty  man-hours  for 
project  office  personnel  should  be  more  than  enough  tor  a  program  of  any  complexity. 
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d.  LESSONS  LEARNED:  There  are  no  lessons  learned  in  the  Automated  Lessons  Learned 
Capture  artd  Retrieval  System  (ALLCARS)  database  on  this  item. 

e.  BEST  PRACTICES: 

(1)  Start  as  early  as  possible  compiling  information  on  U  S.  and  allied  programs  which 
should  be  evaluated  for  ioim  program  appUcabilily.  Corrsideration  to  buy  or  cooperate  at  or  near  the 
Milestone  I  decision  is  too  late  to  effectively  pursue  overseas  opportunities.  Consideration  of  overseas 
opportunities  must  begin  during  development  planning  or,  for  technology  push,  be  an  ou^rowth  of 
ongoing  SAT  cooperation.  Therefore,  K  is  important  to  begin  early  to  investigate  the  various  alternatives 
dealing  with  cooperative  development  programs. 

(2)  The  Defense  Acquisition  Board  (DAB)  will  be  much  more  inclined  to  hold  up 
programs  that  have  not  identified  ways  to  reduce  costs  to  the  U.S.  taxpayer  through  cooperation. 

(Donald  Yockey,  Principal  Deputy  Under  Secretary  of  Defense  for  Acquisilion;  Appearance  before  the 
Senate  Armed  Services  Committee,  12  Jun  90).  This  analyse  should  be  done  to  assist  in  making  a 
decision,  not  just  to  fill  out  the  paper  work! 

f.  TRAPS:  Doni  forget  to  establish  early  a  comprehensive  protection  and  technology  control 
program  to  identify  and  protect  classified  and  other  sensttive  information. 
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1.  ELEMENT:  D43,  TBS  1.2.1 .7  (IFC  93-3) 

2.  ELEMENT  TITLE:  Assess  Technology  Needs 

3.  ELEMENT  OWNER(S):  ASC/YX 

4.  ELEMENT  STAKEHOLOER(S): 

a.  Operating  Commands 

b.  Implementing  Commands 

c.  Product  Centers 

d.  Product  Center  Development  Planning  (XR)  organizations 

e.  Project/Program  Offices 

f.  Wright  Laboratory  (WL) 

g.  Armstrong  Laboratory 

h.  Other  DoO  laboratories 

i.  Logistics  Centers 

j.  Other  Services 

k.  Industry 

5.  REQUIREMENT:  DODI  5000.2.  Defense  AcouisitiQn  Management  Policies  and  Procedures.  23  Feb 
91 

a.  Part  5.  Acquisition  Strategy-  Section  D.  Technology  Transition  and  PrototvoinQ.  This 
requirement  directs  that  the  acquisition  strategy  for  defense  acquisition  programs  identify  plans, 
activities,  and  criteria  tor  assessing  anti  transitioning  critical  technologies  from  technology  development 
and  demorrstration  programs.  Section  D  establishes  the  policies  and  procedures  to  be  followed  to 
accomplish  this  requirement. 

b.  Part  6.  Enoineerino  and  Manufacturing.  Section  A.  Systems  Enaineerino.  This  requirement 
establishes  the  systems  engineering  policies  and  procedures  to  be  followed  for  technology  transition 
efforts. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Translate  critical  technology  needs  and  deficiencies  identified  during  Concept 
Exploration  Studies  (D37)  to  laboratories  (D30)  and  industry  (029). 

b.  Objectives: 

(1 )  Provide  techrwiogy  investment  recommendations  to  laboratories  and  industry  based 
on  operational  requirements  which  cannot  be  met  because  the  technology  to  perform  the  required 
functions  1)  does  not  exist,  2)  is  not  in  development,  or  3)  is  not  planned  to  be  developed. 

(2)  Provide  technical  recommendations,  guidance,  and/or  direction  to  laboratories  and 
industry  in  order  to  influence  the  relevance,  scope,  timeliness,  and  technical  approach  of  ongoing  or 
planned  technology  development  programs  which  have  application  to  the  functional  and  performance 
requirements  of  alternative  design  concepts . 

(3)  Request  assistance  from  laboratories  and/or  irxfustry  to  help  defirre  or  describe 
functions  needed  to  meet  operational  requirements  and  to  identify  technologies  which  could  accomplish 
the  recxjired  functions. 
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7.  DESCRIPTION: 

a.  What  is  Technology  Needs  Assessment? 

(1)  Technology  Needs  Assessmeftt  is  a  Phase  0  activity  perfonned  in  support  of  the 
Requirements  Analysis,  Conceptual  Design,  arxl  Balance  and  Control  compomnts  of  Concept 
Exploration  Studies  (D37).  Although  the  Technology  Needs  Assessment  Element  (043)  is  a  specific 
activity  identified  to  supp^  the  Concept  Exploration  Studies  Element  (D37),  techne^ogy  assessment  in 
gene^  should  have  been  initiated  before  Milestone  0  (see  05,  Techrxiiogy  Area  Assessment)  and 
should  continue  throughout  the  life  of  the  project/program  until  the  need  for  development  and  upgrade 
activities  no  longer  exists. 

(a)  During  ConcefM  Exploration  Studies  (037),  various  altemative  design 
concepts  (and  associated  functional  and  performance  requirements)  are  produced  to  satisfy  the  evolving 
system  requirements.  Using  inputs  from  laboratories  (030)  and  inc^ry  (029),  and  considering  Non 
C^elopmental  Items  (027)  and  possible  C<x)perative  Opc^^unities  (028),  the  functional  and 
performance  requirements  are  compared  with  available  or  projected  techrKtIogies.  Based  on  the  primary 
functional  and  pertormance  requirements  essential  to  meeting  mission  requirements,  the  Concept 
Exploration  Study  team  determines  the  technologies  and  technology  development  programs  which  are 
critical  to  the  success  of  each  altemative  design  concept  and  establishes  a  Critical  Technologies  List. 

(b)  A  determination  is  also  made  of  furx:tional  and  performance  requirements 
which  car  and  cannot  be  satisfied  by  existing  or  planned  technologies.  Technology  needs  are  also 
described  on  the  Critical  Technologies  List. 

NOTE;  For  the  purpose  of  discussion  in  this  document.  Critical  Technology  can  be  defir>ed  as  follows;  A 
scientific  method  which  is  essential  to  performing  a  primary  mission  function  at  a  specific  level  of 
performance. 


(2)  The  Technology  Needs  Assessment  activity  uses  the  Critical  Technologies  List  to 
identify  and  translate  critical  technology  needs  to  the  laboratories  and  industry.  Technology  needs  can 
be  classified  in  different  ways; 

(a)  Technologies  which  do  not  exist,  are  not  in  development,  or  are  not  planned 

to  be  developed. 
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(b)  Developing  techrfologies  which  may  be  relevant  but  whose  current  technical 
approach  arKl/or  schedule  may  not  meet  project/program  requirements. 

(c)  Existing  technologies  requiring  modification  or  further  development  to  meet 

project/program  requirements.  • 

(d)  System  requirements  for  which  fonctional  or  performance  requirements 
cannot  be  fully  defined  nor  ap^icable  technologies  identified. 

b.  Who  does  Technology  Needs  Assessment? 

(1 )  The  Technology  Needs  Assessment  should  be  performed  by  an  integrated 
process  team  (IPT)  formed  to  facilitate  cross  flow  of  technology  information  between  the  project  team 
and  the  l^x>ratories  and  industry.  The  Technology  Needs  IPT  may  be  a  subgroup  of  a  Concept 
Exploration  Studies  IPT.  The  Technology  Needs  IPT  should  be  a  logical  outgrowth  of  the  mission  area 
Technical  Planning  IPT  (TPIPT)  which  p^ormed  the  Pre-Milestone  1  Technology  Area  Assessment 

(05).  ^ 

(2)  In  general,  the  Technology  Needs  IPT  membership  should  include 
representation  from  all  stakeholders  having  responsibility  for  technological  aspects  of  the  project.  IPT 
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membersNp  should  include  project  office  engineers  representirtg  the  primary  engineering  functions  (flight 
systems,  avionics,  crew  systems,  armament  systems,  manufacturing,  support  systems,  training 
systems).  Membership  should  also  include  representation  from  the  operating  command,  development 
planning  (XR),  and  the  laboratories.  If  determined  to  be  appropriate,  industry  contractor  teams  may  also 
be  represent^.  IPT  membership  should  include  individuals  directly  involved  with  concept  exploration 
study  activities  (037).  In  the  interest  of  continuity,  timeliness,  and  quality  of  Technology  Needs 
Assessment  activities,  it  is  highly  recommended  that  membership  also  irickide  TPIPT  members  who 
participated  in  the  Pre-Milestone  1  Technology  Area  Assessment  (05). 

(3)  Although  initially  formed  to  support  the  Phase  0  Concept  Exploration 
Studies,  the  Technology  Needs  IPT  function  should  remain  active  in  order  to  support  ConcefX  Oefinition 
for  Preferred  Alternatives  (037B).  Request  for  Proposal  Preparation  (064),  and  Source  Selection  (070). 
The  Technology  Needs  IPT  function  should  also  continue  throughout  the  life  of  the  project/program  until 
the  need  for  development  and  upgrade  activities  no  longer  exists. 

c.  How  is  Technology  Needs  Assessment  Performed? 

(1 )  Technology  Needs  IPT  Organization.  Based  on  the  scope  and  length  of 
concept  exploration  Studies,  consideration  should  he  given  to  whether  or  not  the  Technology  Needs  IPT 
should  be  formally  chartered  by  the  project  manager.  The  extent  of  formal  organization  should  be  based 
on  the  projected  quantity  and  frequerx^y  of  information  transfer  and  the  need  to  organize  information 
collection  and  information  flow.  The  project  manager  may  want  to  consider  establish  the  Technology 
Needs  IPT  as  the  single  point  of  contact  for  technology  information  collection  as  a  way  to  simplify 
communication  and  to  eliminate  duplication  of  effort. 

(2)  TPIPT  Transition.  The  Technology  Needs  IPT  should  use  information  and 
lessons  learned  from  the  appropriate  mission  area  TPIPT  as  a  starting  point  for  becoming  the  technology 
focal  point  for  Concept  Exploration  Studies. 

(3)  Technology  Awareness.  Technology  Needs  IPT  members  need  to  be  aware 
of  the  scope,  status,  and  sources  of  technologies  applicable  to  the  functional  and  performance 
requirements  of  the  design  concepts  produced  during  Concept  Exploration  Studies.  Technology 
awareness  can  be  developed  through  a  variety  of  activities  including  (see  05,  Techrx^logy  Area 
Assessment,  section  7.c,  for  additional  details): 

(a)  Personal  awareness  due  to  personal  contacts  and/or  regular  reading 
of  technical  periodicals,  professional  journals,  etc. 

(b)  Review  of  laboratory  programs. 

(c)  Technology  development  sponsored  by  other  USAF  programs. 

(d)  Technology  developntent  sponsored  by  other  U.S.  military  services. 

(e)  Literature  Searches. 

(f)  Review  of  industry  independent  research  and  development  (IR&D). 

(g)  Intelligence  information  from  the  Foreign  Aerospace  Science  and 
Technology  Center  (FASTC)  or  other  sources. 

(h)  Technical  conferences,  conventions,  and  symposiums. 

(4)  Technology  Information  Cross  flow.  As  design  concepts  evolve  throughout 
Concept  Exploration  Studies  (D37),  questions  will  continue  to  be  raised  and  information  required  about 
technologies  needed  to  accomplish  functional  and  performance  requirements.  The  Technology  Needs 
IPT,  with  its  breadth  of  expertise,  should  serve  as  the  primary  liaison  and  facilitator  of  information  flow 
between  the  Concept  Exploration  Studies  team  and  the  various  sources  of  technology  information  (D27, 
D28.  D29,  D30). 
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(5)  Technoloav  Needs 

(a)  Technoloav  Needs  Recommendations.  If  it  is  determined  that 
technology  needed  to  accomplish  functional  or  performance  requirements  does  not  exist,  is  not  in 
development,  or  is  not  plann^  to  be  developed,  the  Technology  Needs  IPT  should  prepare  and  issue 
technology  recommendations  reports  (similar  to  the  TIRRs  prepared  by  TPIPTs)  to  the  appropriate 
laboratories.  The  technology  recommertdation  reports  should  be  formal  documents  transmitted  from  the 
project/program  office.  Technology  recommendation  reports  should  include  definitions  of  the  functions 
required  to  be  performed,  required  performance,  cost  guidelines,  and  projected  need  dates.  Having  a 
fomnally  stated  technology  n^,  the  laboratories  can  use  the  technology  recommendations  to  plan  for 
new  technology  program  thrusts.  Laboratory  members  of  the  Technology  Needs  IPT,  with  both 
laboratory  experience  and  knowledge  of  project  concefMual  design  requirements,  can  provide  valuable 
assistance  in  translating  technology  needs  to  the  laboratories. 

(b)  Request  for  Assistance.  At  some  point  during  synthesis  of  individual 
concept  designs,  the  Concept  Exploration  Study  team  may  have  difficulty  defining  certain  functions  or 
levels  of  performance  required  to  meet  mission  requirements.  The  Technology  Assessment  IPT  should 
request  assistance  from  the  laboratories  in  the  form  a  formal  technology  need. 

(6)  Assessment  of  Laboratory  Programs.  Following  review  of  ongoing 
laboratory  technology  development  programs,  it  may  be  determined  that  relevant  technologies  are  being 
developed  but  the  current  technical  approaches  and/or  schedules  may  not  meet  project/program  needs. 
The  Technology  Needs  IPT  should  prepare  and  transmit  formal  technology  program  assessment  reports 
to  the  appropriate  labs.  Program  assessments  should  describe  the  applicability  of  laboratory  programs  to 
project  requirements  and  recommend  changes  in  laboratory  programs  needed  to  meet  proj^  technical 
and/or  schedule  requirements.  Having  formally  stated  technical  guidance  from  a  project/program  office, 
the  laboratories  can  then  justify  modifying  the  appropriate  programs. 

(7)  Assessment  of  Industnr  IR&D.  The  project  Technology  Needs  IPT  can 
participate  in  the  annual  review  of  industry  Independent  Research  and  Development  (IR&D)  programs. 
Through  the  IR&D  review  process,  recommendations  can  be  made  to  industry  on  how  to  adjust  their 
planned  or  ongoing  technology  development  programs  to  meet  concept  design  functional  and 
performance  requirements.  Laboratory  and  industry  representatives  on  the  Technology  Needs  IPT  can 
provide  valuable  assistance  in  translating  technology  needs  to  industry. 

(8)  Contractual  Direction.  If  funding  is  available,  contractual  actions  may  be 
initiated  for  contractor  technology  development  studies  and/or  programs  (see  D35).  Laboratory  and 
industry  representatives  on  the  Technology  Needs  IPT  can  provide  valuable  assistance  to  the  Concept 
Exploration  Studies  team  in  developing  contractual  requirements. 

(9)  Requests  for  Information.  If  specific  information  is  not  available  or  needs  to 
be  developed,  the  Technology  Needs  IPT  can  issue  formal  requests  for  information  to  the  laboratories 
and/or  industry. 
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(fO)  Technotody  Presentations.  The  Technology  Needs  IPT  should  serve  as  tha 
single  point  of  contact  for  coordinating  and  scheduling  laboratory  and  industry  technology  program 
presentations  requested  by  the  Concept  Exploration  Studies  team. 

(11)  FoIIow-Ud.  Since  Concept  Exploration  Studies  is  an  iterative  process 
involving  evolution  of  system  requirements,  design  concepts,  and  functional  and  performance 
requirements,  the  associated  technology  needs  will  also  change.  The  Technology  Needs  IPT  must 
maintain  communication  with  the  organizations  it  has  provided  with  technology  needs,  program 
assessments,  and  recommendations  in  order  to  keep  them  aware  of  changing  requirements.  The  IPT 
should  also  provide  feedback  to  the  Concept  Exploration  Studies  team  on  the  status  of  the  actions  being 
taken  by  the  laboratories  and  industry  in  response  to  formally  stated  project  technology  needs. 


D-410 


ft 


8.  ENTRANCE/EXIT  CRITERIA: 


a.  Enter:  The  Technology  Needs  Assessment  Element  (D43)  could  begin  before  Milestone  0  as 
a  support  function  of  the  Preliminary  System  Corx:^t  Option  Development  Element  (D9),  where  mission 
needs  begin  to  take  form  as  system  concepts.  At  this  point  the  focus  of  technology  assessment  needs 
to  narrow  in  on  technologies  required  to  form  specific  functions  derived  from  earfy  system  corx^epts  (D9). 
as  opposed  to  the  more  general  Technology  Area  Assessment  (D5)  performed  by  mission  area  TPIPTs. 

It  is  better  that  Technology  Needs  Assessment  begin  earlier  than  later,  but  no  later  than  the  start  of 
Ck>ncept  Exploration  Studies  (037). 

b.  £xji:  The  Technology  Needs  Assessment  Element  should  continue  at  least  as  long  as  the 
Concept  Exploration  Studies  Element  (037)  and  should  continue  until  all  necessary  follow-up  actions 
have  been  completed.  Consideration  should  be  given  to  maintaining  the  Technology  Needs  function/I  PT 
throughout  the  remainder  of  Phase  0  in  order  to  support  Concept  Definition  for  Preferred  Alternatives 
(D37B).  Request  for  Proposal  Preparation  (064),  and  Source  Selection  (070).  Regardless  of  whether 
Elements  05  or  043  continue  as  specifically  identified  element  names  or  numbers,  a  permanent 
technology  assessment  function  should  be  established  in  order  to  maintain  awareness  of  applicable 
technology  developments  throughout  the  life  of  the  project/program  until  the  need  for  development  and 
upgrade  activities  no  longer  exists. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1 )  Mission  Area  Development  Plans  from  mission  area  TPIPTs  (05). 

(2)  Technology  Investment  Recommendation  Reports  (TIRRs)  from  mission  area 

TPIPTs  (05). 

(3)  Concept  Design  Functional  and  Performance  Requirements  from  Concept 
Exploration  Studies  (037). 

(4)  Critical  Technologies  List  from  Concept  Exploration  Studies  (37). 

(5)  Review  of  Non  Developmental  Items  (NDI)  (027). 

(6)  Review  of  Cooperative  Opportunity  Exploration  (028). 

(7)  Technology  Program  Reviews  from  WL/XP  (030). 

(8)  Technology  Plans  for  Wright  Laboratory  from  WL/XPR  (030). 

(9)  Technology  Area  Plans  from  WL/XPT  (030)  and  OTIC  (WUDOC). 

(10)  IR&D  Annual  Program  Reviews  (WL/XPR)  (029/030). 

(11)  IR&D  Annual  Plans  and  Reports  (WL/XPR)  (029/030). 

(12)  Literature  Searches  (WL/DOC).  The  Wright  Laboratory  Technical  Library 
would  be  the  primary  facilitator  for  accomplishing  literature  searches.  WL-assisted  literature  searches 
will  allow  you  to  search  the  OTIC  and  other  information  databases  through  which  you  should  be  able  to 
find  information  on  technology  development  programs  of  DoD  laboratories  other  than  WL. 

b.  Outputs: 

(1)  Technology  Investment  Recommendation  Reports. 

(2)  Requests  for  Technical  Assistance. 

(3)  Laboratory  Program  Assessment  Reports. 

(4)  Industry  IR&O  Evaluations. 

(5)  Technical  Requirements  for  RFPs. 

(6)  Requests  for  Information. 

10.  KEY  REFERENCES:  See  paragraph  5,  Requirement,  above. 

1 1 .  IMPLEMENTATION  TOOLS: 


a.  See  paragraph  9.a,  Inputs,  above. 
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See  Element  D5. ; 


i,  paragraph  7.c,  ] 


c.  Databases  such  as  the  Defense  Technical  Information  Center  (DTIC)  and  "UnCover*  (contact 
Wright  Laboratory  Technical  Library.  WL/DOC). 


d.  Prc^essional  journals,  technical  periodicals,  conventions/conferences  and  proceedings. 


12.  PLANMNG  GUIDANCE: 


a.  DURATION:  The  duration  of  the  Technology  Needs  Assessment  Element  is  dependent  upon 
the  scope  of  project/program  elements  to  be  supported  (see  paragraph  8.  Entrance/Exit  Criteria,  above). 
If  the  performed  only  in  support  of  the  Concept  Exploration  Studies  Element  (D37),  the  duration  can 
range  from  several  months  to  2  years.  If  the  Technology  Needs  Assessment  activity  is  established  to 
support  earlier  or  later  elements,  additional  time  will  be  added  to  the  duration.  Although  Technology 
Needs  Assessment  activities  may  span  a  period  of  months  or  years,  it  will  most  likely  involve  a  series  of 
short  term  projects  spread  intermittently  over  the  entire  period. 


b.  CONSTRAINTS: 


(1 )  Maintaining  awareness  of  technology  development  efforts  across  government  and 
industry,  nationally  and  internationally,  can  be  very  time  consuming. 


(2)  In  addition  to  being  time  consuming,  obtaining  complete  information  on  technology 
development  efforts  from  all  DoD  laboratories,  other  services,  industry,  and  foreign  sources  can  be 
difficult.  Information  on  'black  workf  program  technology  development  is  not  available  within  the 
general  laboratory  community. 


(3)  Time  and  program  funds  are  predictable  constraints  that  will  impact  technology 
assessment  activities.  Inadequate  definition  of  operational  functional,  and  performance  requirements  will 
complicate  the  ability  to  translate  technology  needs  to  the  laboratories  and  industry  and  may,  in  turn, 
adversely  impact  schedule  and  the  quality  of  the  of  Concept  Exploration  Study  results. 


RESOURCES: 


(1 )  People.  As  described  in  paragraph  7.b.(1 ),  above,  the  Technology  Needs 
Assessment  activity  requires  representation  from  all  stakeholders  having  responsibility  for  technological 
aspects  of  the  proj^.  People  resources  should  include  project  office  engineers  representing  the  primary 
engineering  functions  (flight  systems,  avionics,  crew  systems,  armament  systems,  manufacturing, 
support  systems,  training  systems),  as  well  as  representatives  from  the  operating  command, 
development  planning  (XR),  the  laboratories,  others  as  required  and  industry  (if  determined  to  be 
appropriate).  For  a  weapon  system  acquisition  project  of  the  scope  of  the  F-22  or  Multi-Role  Fighter, 
approximately  10-20  people  could  be  assigned  to  participate  in  technology  assessment  with  additional 
support  as  needed.  It  is  important  to  note  that  although  Technology  Needs  Assessment  activities  may 
span  a  period  of  months  or  years,  that  work  will  most  likely  come  in  a  series  of  short  term  projects  and 
probably  will  not  require  long  term  full  time  commitment  of  people.  It  is  feasible  that  the  people  involved 
in  Technology  Needs  Assessment  would  also  be  assigned  to  the  Concept  Exploration  Studies  team  or 
other  activities. 


(2)  Financial.  Funding  should  be  made  available  for  travel  for  Technology  Needs 
Assessment  people  to  attend  program  reviews,  conferences,  conventions,  etc.,  visit  contractors,  and  to 
purchase  conference  proceedings,  subscriptions  to  technical  journals  and  periodicals,  etc. 
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d.  LESSONS  LEARNED: 


(1)  June  1993  MRFP  Technology  Assessment 


(a)  In  June  1993  the  USAF  Multi  Role  Forces  Project  (MRFP)  Office  requested 
that  the  ASC  Program  Development  SPO  Engineering  Division  (ASC/YXE)  perform  a  technology 
assessment  of  laboratory  programs  applicable  to  a  F-1 6  follow-on  weapon  system.  The  review  primarily 
concentrated  on  programs  presented  at  the  1993  Wright  Laboratory  Spring  Review. 

(b)  Approximately  10-15  engir>eers  involved  in  the  June  1993  ASC/YXE  MRFP 
technology  assessment  attended  the  WL  Spring  Review.  The  Spring  Review  was  held  during  the  first 
week  of  May  1993  and  lasted  approximately  five  working  days.  Approximately  20-30  engineers  from 
YXE,  other  SPOs,  and  ASC/EN  ^nctional  organizations  participated  in  the  evaluation  of  the  lab 
programs  for  the  MRFP. 


(c)  Out  of  the  200  or  so  technology  development  programs  presented  at  the 
WL  Spring  Review,  approximately  70  were  identified  as  being  applicable  to  the  MRFP.  Each  of  the  70 
programs  were  evaluated  and  scored  by  individual  engineers.  Composite  scores  were  compiled  for  each 
program  and  presented  to  a  core  team  of  senior  engineers  who  established  the  final  scores.  This  core 
team  consist^  of  approximately  eight  people  representing  MRFP  program  management  (ASC/YXM), 
Program  Development  Engineering  (ASC/YXE),  development  planning  (ASC/XR),  and  Wright 
Laboratory.  This  effort  lasted  a  total  of  approximately  3  weeks.  Individual  time  spent  ranged  from  1-2 
hours  to  2-3  days  with  the  over  a  period  of  approximately  3  weeks. 

e.  BEST  PRACTICES:  None  identified  as  of  this  date. 

f.  TRAPS: 

(1 )  Failure  to  organize  the  Technology  Needs  Assessment  process  into  a  coordinated 
e^ort  which  involves  all  the  proper  stakeholders  will  likely  result  in  duplication  of  effort  and  conflicting 
assessments  of  technology  development  programs. 

(2)  Technology  development  is  like  i'rfe;  it  goes  on.  You  can  continue  to  search  for  and 
evaluate  technology  forever.  Therefore,  the  scope  of  Technology  Needs  Assessment  activities  should 
be  clearly  defined  and  reasonable  time  constraints  should  be  established  based  on  the  needs  of  Concept 
Evaluation  Studies. 
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1.  ELEMEMT:  044.  TBS  1.2.1. 6  (IFC93-3) 

2.  ELEMENT  TITLE:  Update  Database 
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3.  ELEMENT  OWNERS:  Operating  Command,  Implementing  Command.  Product  Center  Development 
Planning  Oireciorate  (XR)  and  Pregram  Development  SPO  (ASC/YX),  industry 

4.  ELEMENT  STAKEHOLDERS: 

a.  Implementing  Agencies:  Oepartmento<De(ense(DOD),  Secretary  of  the  Air  Force  (SAP), 
Implementing  Command,  Product  Center  XR  and  YX  (ASC). 

b.  Supporting  Agencies:  Air  Force  Intelligence  St^jport  Agency  (AFISA),  Air  Force  Studies  and 
Analysis  Agency  (AFSAA),  Laboratories.  Industry,  Operating  Commands. 

5.  REQUIREMENT: 

a.  Air  Force  Policy  Directive  (AFPD)  10-6,  Mission  Needs  and  Operational  Requirements,  19 
Jan  93:  This  directive  requires  the  irr^ementation  of  the  DOD  5000  series  documents,  which  in  turn 
requires  the  maintenance  of  database. 

b.  AFPD  37-1 ,  Information  Management:  (On  order,  upon  receiving  docun^t,  the  definition 
will  be  constructed) 

c.  AFPD  63-1,  Acquisition  System:  (On  order) 

d.  AFR  55-43,  Management  Operations,  Test  and  Evaluation.  29  Jun  90:  This  regulation 
describes  the  support  document  requirements  and  the  Data  Management  and  Analysis  Plan. 

e.  Department  Of  Defense  Directive  (DODD)  5000.1 ,  Defense  Acquisition,  23  Feb  91 : 
Establishes  a  disciplined  management  approach  for  acquiring  systems  and  materiel  that  satisfy  the 
operational  user's  needs. 

f.  DODD  8320.1 ,  Data  Administration,  26  September  1990:  (On  order). 

g.  MIL-STD-1388-1  A,  Logistics  Support  Analysis  (LSA),  11  Apr  83:  The  goal  of  this  standard  is 
a  single,  uniform  approach  by  the  Military  ^rvices  for  conducting  activities  necessary  to  cause 
supportability  requirements  to  be  an  integral  part  of  system  requirements  arxi  design,  with  documentation 
developed  and  maintained. 

h.  MIL-STD-4996,  Systems  Engineering,  Draft:  The  decision  database  may  be  digital,  defined 
by  the  Government  or  left  open  for  contractor  definition. 

i.  MIL-STD-1388-2B,  DOD  Requirements  tor  a  Logistics  Support  Analysis  Record,  28  Mar  91 : 
This  standard  is  directed  toward  improving  the  cost  effectiveness  of  the  generation,  maintenance, 
acquisition,  and  use  of  the  technical  data  required  to  support  an  LSA  program. 

j.  MIL-STD-1840A,  Automated  Interchange  of  Technical  Information,  22  Dec  87:  The  purpose 
of  this  standard  is  to  standardize  the  digital  interface  b^ween  organizations  or  systems  exchanging 
digital  forms  of  technical  information  necessary  for  the  logistic  support  of  weapon  systems  throughout 
their  life  cycle. 


«) 


•  • 


D-415 


NMtS 


6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  purpose  of  the  Program  Database  is  to  provide  a  central  location  tor  the 
collection  and  storage  of  intormation/data.  This  intormation/data  will  support  the  Protect  Teams  in 
making  decisions  that  resporxt  to  external  and  internal  requirements,  (i.e.  the  information  needs  of 
milestone  decision  authority). 

b.  Objective:  At  this  point  the  database  is  updated  using  Phase  0  project  activities  planrred  since 
the  update  of  Project  Database.  D31 . 

7.  DESCRIPTION: 

a.  The  database  is  the  update  of  information  used  arto  generated  tor  integrated  requiremerts 
and  flowdowns;  interface  constraints  and  configuration  altematives.  verifications;  decision  criteria,  trade 
study  assessments,  and  any  other  required  documents.  It  includes  physical  and  mathematical  models, 
computer  simulations,  layouts,  artd  similar  configuration  documentation  arto  technical  data,  as 
appropriate.  The  performing  activity  selects  the  specific  data  entry  media,  storage,  and  maintenance 
procedures.  At  this  stage  the  database  captures  the  operational  requirements  developmerrt.  Starting  with 
the  updated  phase  0  plans,  the  contracted  studies  (D35)  feed  into  Concept  Exploration  (D37)  studies.  It 
must  contain  significant  information  of  use  of  off-the-shelf  (Non  Development ,  D27))  items  as  well  as 
Cooperative  Op|X)rtunities  (D28). 

b.  The  preliminary  user  of  tNs  stage  of  data  depository  is  the  Altemative  Systems  Review  (D45) 
and  Conducting  the  Comparative  COEA  Analysis  (D48)  arto  Program  Alterrrative  Analysis(D46).  The 
data  will  be  complemented  from  technology  status  information  and  will  be  used  for  further  defining 
requirements  artd  corrcepts. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  This  is  a  continuous  activity,  interxied  to  be  current  since  established  in  D1 5,  and 
updated  in  D31 . 

b.  Exit:  The  Data  Base  will  continually  be  updated  throughout  the  pre-milestone  1  process  and 
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beyond. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Input:  ^ 

(1)  From  Concept  Exploration  Studies  (D37) 

(a)  Requirements  Analyses 

(b)  Updated  COEA  I  Plans 

(c)  Upd^ed  Systems  Requirement  Document  (SRD) 

(d)  Revised  Baseline  Concept  Description  ( BCD) 

(e)  Concept  Synthesis  and  Evaluation  • 

(f)  Effectiveness  Evaluation 

(2)  Other  approved  pertinent  data  since  D31 

b.  Output: 

(1 )  All  above  inputs  can  be  utilized  as  outputs.  • 

(2)  Other  approved  data  from  any  source. 


D-416 


•  •  •  ^  •  • 


NMt3 


10.  KEY  REFEf^NCES:  (In  addition  to  those  listed  in  Requirements.  Paragraph  S) 

a.  Air  Force  Instruction  (API)  10-601 .  Mission  Needs  and  Operational  Requirements  Guidance 
and  Procedures,  16  Feb  93:  Identifies  official  Air  Force  information  required  for  decision  making  and 
historical  purpose  and  develop  a  schedule  of  the  information  life  cycle  to  describe  creation, 
maintenance,  and  disposition  (API  37-123,  Management  of  Records). 

b.  AP1 10-602,  Logistics  Support  and  Readiness  Requirements:  (On  order,  upon  receiving 
document,  the  definition  will  be  written.) 

c.  AF1 14-303,  Threat  Support,  Acquisition  Process.  (On  order). 

d.  AP1 16-501 ,  Control  and  Documentation,  Air  Force  Programs:  (On  order). 

e.  API  33-105,  Information  System,  Standard  Programs:  (On  order). 

f.  API  37-1 ,  Information  Management:  (On  order). 

g.  API  37-123.  Management  of  Records:  Identifies  the  activities  to  plan,  design,  model, 
synchronize,  standardize  and  control  Air  Force  Corporate  data  at  all  echelons. 

h.  API  37-150,  Data  Administration  and  Standards  Program:  (On  order). 

i.  DOD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 :  Establishes  an  integrated  framework  for  translating  broadly  stated  mission  needs  into  stable, 
affordable  acquisition  programs  that  meet  the  operational  user's  needs  and  can  be  sustained,  given 
projected  resource  constraints. 

j.  DOD  Manual  5000.2M,  Defense  Acquisition  Management  Documentation  and  Reports,  23  Feb 
91 :  This  Manual  implements  relevant  portions  of  DODD  5000.1  and  DODD  5000.2.  Specific 
responsbilities  pertaining  to  major  areas  are  provided  in  each  individual  section,  as  appropriate. 

k.  Implementing  Command:  Submit  required  acquisition  program  documents.  (Defense 
Planning  Guide,  Mission  Area  Assessment,  and  Mission  Needs  Arralysis,  etc.). 

l.  MIL-HDBK-59A,  DOD  Computer-Aided  Acquisition  and  Logistic  Support  (CALS)  Program 
Implementation  Guide:  The  purpose  of  this  military  handbook  is  to  provide  general  information  and 
detailed  applicatbn  guidance  for  contractually  implementing  CALS  requirements  in  weapon  system  and 
related  major  equipment  procurements. 

m.  MIL-HDBK-X499-3.  Systems  Engineering/Configuration  Management.  Draft:  The  decision 
database  will  provide  an  audit  trail  from  initially  stated  needs  and  requiremerrts  to  the  current  description 
of  system  products  and  processes. 

n.  Secretary  of  the  Air  Force  (SAF/AAI):  SAF/AAI  will  ensure  compliance  with  DOD  Corporate 
Information  Management  (CIM)  to  allow  sharing  of  data  with  appropriate  DOD  agencies  arxf  other 
Government  agerx:ies. 

0.  Supporting  Command:  The  Supporting  Command  win  collect  and  process  Integrated  Logistic 
Support  (ILS)  information  in  the  Logistics  Mar^ement  Informatbn  System  (LMIS).  Outline  the  actons, 
support,  and  documentation  needed  to  establish  maintenance  requirenrents  for  on  and  off  equipment 
throughout  the  life  of  the  system.  Identify  data  collection  arxf  analysis  efforts  that  will  continue  after 
fielding  of  system  equipmerti. 
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p.  Using /Opsrating  Command:  The  user  waM  ensiua  and  management  needs  are 
identified.  Integrate  the  Logistics  Support  Analysis  process  with  the  System  Requirements  Analysis 
activity.  CXAIine  the  actions,  support,  and  documentation  needed  to  establish  maintenance  requirements 
(or  on  and  off  equipment  throughout  the  life  of  the  system. 

11.  IMPLEMENTATION  TOOLS: 

a.  Automated  Data  Processing  (AOP)  is  avaHarisle  as  Government  Furnished  Property  (GFP). 

Contact; 

Director  USAMC  Logistic  Support  Activity 
ATTN.:  AMXLC-AL 
Lexington,  KY  4051 1-5101 
606-293-4193  (Mr.  David  Henderson) 

b.  Computer-Aided  Acquisition  and  Logistic  Support  (CALS):  The  repository  of  information  used 
and  generated  at  the  appropriate  level  for  the  acquisition  phase  of  integrated  requirements  and 
flowdowns;  interface  constraints  and  requirements;  functional  and  performance  requirements;  system 
concept;  preliminary  design  and  configuration  alternatives:  details  design;  verifications:  decision  criteria; 
trade  study  assessments;  system,  subsystem,  and  functional  capability  assessments;  and  other  required 
documentation. 


(a)  MIL-HDBK-59A 

(b)  MIL-STD-1840A 

c.  Systems  and  Logistics  Integration  Capability  (SLIC);  This  is  a  state-of-the-art,  DOD  Type  III 
validated,  micro  computer  based  LSAR  system  that  can  be  used  to  completely  satisfy  all  MIL-STD-1388- 
2A  requirements  with  total  irxfependence  from  any  other  hardware  and  software. 

(a)  SLIC  I 

(b)  SLIC  II 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Update  the  database  continuously  throughout  the  life  cycle  of  the  product. 

b.  CONSTRAINTS: 

(1)  Identify  computer  resource  constraints  (examples  include  language,  computer, 
database,  architecture,  or  interoperability  constraints). 

(2)  Database  capacity  (identify  spare  memory  and  throughput  requirements,  computer 
memory  growth  requirements,  software  partitioning  and  modular  design  requirements  such  as  software 
module  size,  (e.g.  no  greater  than  100  lines  of  code). 

(3)  Access  capabilities 

(4)  Security  restrictions 

(5)  Time 

(6)  Assumptions 


$ 
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(7)  Funds 

(8)  Management  Resources 

(9)  Training 

e.  RESOURCES: 

(1)  Faeries 

(a)  Classified  work  space 

(b)  Personnel  office  space  and  s(4>piies 

(c)  Database  location 

(2)  Computer  hardware  and  software  programs 

(a)  Analytical  models 

(b)  Program  Management  Software 

(3)  Security 

(a)  Type  of  access  required 

(b)  Provide  access  for  contractors 

(4)  Manpower 

(a)  Security  personnel 

(b)  Computer  systems  personnel 

(c)  Data  management  personnel 

D.  LESSONS  LEARNED:  (First  two  lessons  transcribed  from  ALLCARS,  the  others  are 
referenced) 

(1)  « 1962,  P^ram  Directors;  Enhanced  quality  and  quantity  of  information  on  the  AFAM 
database.  Improvements  include  additional  lessons  learned  and  be^  practices,  updated  references, 
increased  number  of  tools  such  as  software  programs,  document  templates,  samples,  and  courses.  (Col. 
Ferrell.  ASC/CYM,  DSN  785-2213) 

(2)  #1344,  Schedule  Plan  For  A  Source  Selection;  Develop  a  detailed  plan  for  the 
execution  of  source  selection  that  will  aid  the  flow  of  data  and  provide  expedient  changes  to 
contingencies.  All  data  were  computerized  on  an  IBM  program  caNed  ’Super  Project.*  The  data  were 
placed  in  a  network  to  deffoe  the  internal  relationships  of  activAies  and  resources  and  a  Garm  chart  was 
used  to  provide  schedule  suspense  dates  arxJ  serve  as  a  tracking  tod.  By  computerizing  the  data  base 
’what-iT  scenario's  could  be  evaluated  based  on  unkrxiwn  contingencies  (i.e.,  slip  of  data  reviews, 
modifications  to  the  proposals,  personnel  conflicts  or  absences).  The  database  was  used  as  a  living 
tod”  to  help  manage  200  evaluators,  18  evaluation  items,  and  7  proposals.  (POC  will  be  added  at  later 
date.) 


•  • 


(3)  #  1264,  AFLC  LMS  Target  Operating  Environment. 

(4)  #1418,  Irrtemal  Financial  Management. 

(5)  #1888,  Program  Managers. 

(6)  #  1962,  Program  Directors. 

(7)  #  9020,  Hardness  Surveillance  Test  Systems  (PHSTS). 
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(8)  #  9063.  Air  Force  Electronic  Combat  OHice  (AFECO ). 

(9)  #911S.ASIAC. 

(10)  #9116,  Reliability  Analysis  Center  (RAC). 

E.  BEST  PRACTICES:  Use  MIL-HDBK-59A,  000  CALS  Program  Implementation  Guide,  and 
MIL-STO-1840A,  Automated  Interchange  of  Technical  Information  to  control  data  storage  wtth  frequent 
backups  to  avoid  the  loss  of  data. 

F.  TRAPS:  Nonoompatible  CALS  systems  have  problems  with  nonstandard  terminology  used 
to  file  or  retrieve  data. 
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1.  ELEMENT:  D45,  TBS  1  2.1 .5  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  Attemative  System  Review  (aka-  Concept  Alternatives  Review  (CAR)) 


f 


3.  ELEKENT  OWNER(S):  Project  Cadre  (at  ASC,  it  is  typiCv  .y  YX;  at  other  Product  Centers,  it  is  XR 
members):  Project  Cadre  consists  of  a  core  of  functional  r^esentatives,  e.g.  operating,  implementing, 
and  supp^  commands,  product  arxj  logistic  centers,  laboratories,  etc. 

4.  ELEMENT  STAKEHOLOER(S): 

a.  Project  Cadre, 

b.  Product/Logistics/Test  Centers, 

c.  Operating,  Implementing  and  ^pporting  Commands, 

d.  Lf^boratories, 

e.  Intelligence  Agencies. 

5.  REQUIREMENT: 

a.  0001 5000.2,  Oefense  Acquisition  Management  Policies  &  Procedures,  Jan  91 : 

(1)  Part  2,  Section  B,  General  Policies  &  Procedures, 

(2)  Part  4,  Requirements  Evolution  and  Affordability,  and 

(3)  Part  7,  Logistics  &  Other  Infrastructure  for  total  system  concerns; 

b.  0001  5000.2-M,  Oefense  Acquisition  Management  Oocumentation  &  Reports,  Feb  91 ; 

(1)  Part  3,  Operational  Requirements  Oocument,  and 

(2)  Part  8,  Cost  and  Operational  Effectiveness  Report; 

f  c.  Military  Standard  (MIL-ST0)-499B,  Systems  Engineering,  Oraft  May  92,  Section  3.8,  Systems 

Engineering  Process. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  CAR  is  a  comprehensive  integrated  review  activity  that  is  conducted  to 
examine  the  systems  analysis  products  for  each  concept  alternative  under  consideration.  It  supports  the 
determination  of  the  completeness  of  the  concept  explorations  and  is  the  basis  for  recommending  which 
system/subsystem/equipment  concepts  should  continue  as  candidates  for  application  in  the  Cost  and 
Operational  Effectiveness  Analysis  (COEA). 

b.  Objectives:  The  objectives  are  to  assess: 

1 )  development  of  each  concept  alternative  for  its  ability  to  satisfy  identified  customer 
needs  and  operational  objectives, 

2)  the  factors  (performance,  cost,  schedule,  risk)  for  achievable/affordable  development, 
and 

3)  the  accomplishments  of  the  planned-for  or  contracted-for  tasks  against  the  Systems 
Engineering  Master  Plan  (SEMP)  criteria. 

7.  DESCRIPTION: 

a.  The  CAR  is  conducted  by  the  Project  Cadre  and  may  be  a  one-time  occurrence  or  a 
.  sequence  of  interim  activities.  Whichever  approach  is  selected,  the  implementing  command's  system 
developer  is  usually  the  host/chair  at  appropriate  government  or  contractor(s)  facilities.  If  an  interim 
approach  is  select^,  a  final  wrap-up  session  to  assure  overall  system  integration  is  necessary. 
Attendance  at  the  reviews  should  include  the  Project  Cadre  and  those  government  personnel  with  special 
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contributing  interests:  e.g.  intelligence  source,  interfacing  systems/equipntent,  etc.  The  details  of  topics 
to  be  reviewed  are  in  the  same  scope  as  those  identified  for  an  Alternative  System  Review  (ASR):  see 
Paragraph  5.9.3.4.2  of  Ref  (c)  in  S^ion  5,  above  for  nrKxe  details  on  the  ASR. 

b.  The  efforts  and  prochjcts  of  the  activities  from  D37,  Conduct  Concept  Exploratbn  Studies 
(e.g.  systems  analyses,  su(^  as  functional  analysis,  mission  analysis,  performance  analysis,  conceptual 
design/synthesis,  and  performance  and  effectiveness  trade  studio)  are  reviewed  and  assessed  for 
applicability,  thoroughness,  consistency  and  validity.  The  operational  and  functional  requirements  from 
D37  are  also  evaluated  for  each  alternative  concept's  ability  to  satisfy  the  need  specified  in  the  Mission 
Need  Statement  (MNS)  (C21 ).  The  overall  satisfaction  of  conditions  and  rquirements  listed  in  the 
Program  Management  Directive  (PMD)  is  also  checked.  Concept  configurations,  as  documented  in  the 
Baseline  Concept  Description  (BCD)  during  D37  execution,  are  used  as  a  basis  to  assess  each  concept 
tor  MNS  satisfa^ton.  They  are  also  assessed  in  conjunction  with  the  performance  arto  effectiverress 
trade  studies,  achievability,  technology  availability  and  cost  estimates.  These  are  important  aspects  to 
be  used  in  the  COEA I  that  follows  which  will  be  determining  relative  areas  of  concept  risk,  effectiveness, 
and  affordability. 

c.  During  the  review,  the  concept  candidates  are  evaluated  for  their  worthiness  for  application  to 
the  COEA  I  (which  will  be  providing  system  component  descriptions  -  a  level  2  focus  -  for  selection  of 
preferred  corKepts  for  further  study  in  Demonstration  and  Validation  (Dem-Val)  Phase).  The  Risk 
Analysis  for  each  concept  is  assessed,  as  is  the  risk  reduction  strategy,  in  the  Risk  Management  Plans. 
Also  identified  are  preliminary  areas  that  would  be  required  to  be  addressed  in  Dem-Val  by  contractor 
participants;  in  particular,  recommendations  for  DerrWal  Prototyping  and  Validation  testing  for  risk 
reduction.  The  CAR  is  also  used  to  initiate  the  coordination  of  the  System  Requirements  Docurnem 
(SRD)  and  the  draft  Operational  Requirements  Document  (ORD).  A  strawman  outline  is  generated  for 
the  related  Requirements  Correlation  Matrix  (RCM)  (C19).  The  SEMP  entrance  criteria  (readiness)  is 
applied  for  the  CAR  events  and  the  exit  criteria  (accomplishment)  is  applied  for  completion  (C21 ).  The 
results  are  documented  and  normally  incorporated  into  the  project  database  (D46). 

8.  ENTRANCBEXIT  CRITERIA: 

a.  Entrance;  This  activity  can  begin  when  sufficient  concept  exploration  tasks  have  been 
completed  and  required  data  is  available. 

b.  Exit:  This  activity  concludes  when  the  reports  to  decision  makers  (i.e.  COEA  I CAG)  on  the 
concept  alternatives  are  approved,  and  the  SEMS  accomplishment  criteria  have  been  declared  met  (see 
Section  5,  Ref  c). 

9.  KEY  INPUTS  AND  OUTPUTS: 

Inputs;  a.  D37  results  (Conduct  Concept  Exploration)  and  D44  updates  (Data  Base),  (e.g. 
Requirements  Analyses.  Conceptual  Designs,  Studies  and  Analyses,  Functional  Architectures. 
Specification  Trees,  Work  Breakdown  Structure  (WBS),  SRDs,  SEMS,  Risk  Management  Plan  &  BCDs) 

b.  MNS. 

c.  PMD. 

d.  Interim  review  minutes,  including  SEMP,  Contract  Statement  of  Work,  (infractor 
Briefings  and  SEMS. 

e.  Draft  ORD. 

Outputs:  a.  "Changes*  to  Technical  Data  (D46). 

b.  MNS  Satisfaction  Report  (C21). 

c.  Outline  of  Technical  Exit  Criteria  for  Phase  I  (C21  &  D46). 

d.  SEMP  Report  (C21). 

e.  Minutes  -  from  reviews  of  each  concept  (D46). 
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f.  Strawman  RCM.  (C19). 

10.  KEY  REFERENCES: 

Section  5.  Requirefnent(s)  plus: 

a.  AF  1/  DOOl  5000.2,  Acquisition  Management  Policies  &  Procedurss.Sep  92.  Part  2, 
Section  B,  Policies  tor  interface  managemer^. 

b.  MIL-HNBK-499-3.  System  Engineering  /  Ck>nfiguration  Management  (SE/CM)  -  Life  Cycle 
Application,  Draft  Aug  92,  Guidelines  for  system  reviews. 

c.  MIL-STD-1521 ,  Technical  Reviews  and  Audits  for  Systems.  Equipments  and  Computer 
Software,  Appendix  A,  1988. 

d.  Systems  Engineering  Management  Guide,  DSMC,  Jan  91, Identification  of  relevant  directives 
and  references  for  systems  engineering  concepts. 

11.  IMPLEMENTATION  TOOLS: 

a.  System  Review  Outlines  from  Systems  Engineering  Management  Guide. 

b.  MIL-STD-499B,  Systems  Errgineering,  Section  5  -  Detailed  Requirements  and  Appendix  C  - 
General  Guidance  on  the  Conduct  of  Technical  Reviews. 


» 
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c.  MIL-STD  1 521 ,  Technical  Reviews  and  Audits  for  Systems,  Equipments,  and  Computer 
Software. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Equivalent  to  1*3  day  review  for  each  alternative  (or  grouping  of)  concepts. 

b.  CONSTRAINTS:  Matching  the  level  of  detail  developed  with  that  expected  /  needed  by  the 
COEA  Concept  Advisory  Group  (CAG):  see  Cl  6.  Update  Phase  0  Plans. 

c.  RESOURCES:  Project  Cadre,  including  Operating  Command,  PC/ALC,  Laboratory,  System 
Program  Director/Product  Group  Manager/Material  Group  Manager  (SPD/PGM/MGM). 

d.  LESSONS  LEARNED: 

1 )  Incremental  reviews  can  be  more  efficient  atxf  effective  by  allowing  concerted  scrubs 
on  specific  functional  areas. 

2)  Reviews  should  be  segregated  by  concepts  to  permit  a  more  focused  effort. 

3)  Specific  meeting  agendas  and  responsibilities  should  be  developed  as  a  means  of 
tracking  progress  and  staying  on  track  during  the  review  and  knowing  where/who  has  key  review 
functions. 


» 
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e.  BEST  PRACTICES:  None  Identified. 

f.  TRAPS:  Acceptance  of  verbal  presentations  and  (X)mmitments;  documentation  is  very 
important. 

» 
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1.  ELEMENT:  D45B,  TBS  1. 2.4.4  (IFC  93-3) 

2.  ELEMENT  TITLE:  Preferred  Altematives  Review  (PAR) 

3.  ELEMENT  OWNER(S):  Project  Cadre  (at  ASC,  it  is  typically  YX;  at  other  Product  Centers,  it  is  XR 
members);  Project  Cadre  consists  of  a  core  of  functional  representatives,  e.g.  operating,  implementing, 
and  suppM  commands,  product  and  logistic  centers,  laboratories,  etc. 

4.  ELEMENT  STAKEHOLOER(S): 

a.  Project  Cadre. 

b.  Product/Logistic&Test  Centers. 

c.  Operating,  Implementing  and  Supporting  Commands. 

d.  Laboratories. 

e.  Intelligence  Agencies. 

f.  USAF/XO  &  SAF/AQ. 

5.  REQUIREMENT: 

a.  OODI  5000.2,  Defense  Acquisition  Management  Policies  &  Procedures,  Jan  91 : 

(1)  Part  2,  Section  B,  General  Policies  &  Procedures. 

(2)  Part  4,  Requirements  Evolution  arxf  Affordability. 

(3)  Part  7,  Logistics  &  Other  Infrastructure  for  total  system  concerns. 

(4)  Part  1 1 ,  Sections  C,  D  &  E.  Program  Control  and  Review. 

DOOI  5000.2-M,  Defense  Acquisition  Management  Documentation  &  Reports,  Feb  91 ; 

(1 )  Part  1 ,  Procedures  and  formats  for  use  in  preparations  for  milestones,  reviews  and 
decision  activities. 

(2)  Part  3,  Operational  Requirements  Document. 

(3)  Part  8,  Cost  and  Operational  Effectiveness  Report. 

c.  Military  Standard  (MIL-STD)-499B.  Systems  Engineering,  Draft  May  92,  Section  3.8,  Systems 
Engineering  Process. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  This  PAR  activity  is  a  comprehensive  quality  review,  particularly  with  respect  to  the 
system  component  and  configuration  item  (WBS  level  3)  details,  before  approving  for  transfer  to  the 
Lead  MAJCOM  fortheir  AfS  1  decision  package. 

b.  Objectives:  The  objectives  are  to: 

(1)  ensure  consistency  and  level  of  detail  for  the  preferred  alternative(s), 

(2)  update  and  finalize  documentation  of  outlines  for  the  Plans,  Schedules  and  System 

Desertions, 

(3)  define  technical  goals  and  objectives  for  Phase  1  program, 

(4)  finalize  plans  for  identified  risk  reduction  efforts. 

7.  DESCRIPTION:  The  PAR  is  conducted  by  the  Project  Cadre  and  may  be  performed  more  than  once, 
(i.e.  interim  reviews).  It  is  to  assess  the  technical  adequacy  and  scope  of  the  altemative(s),  defined  in 
Concept  Definition  for  Preferred  Altemative(s)  block  D37B,  including  the  interface  and  operability 
issues.  An  emphasis  should  be  placed  on  reviewing  areas  for  reducing  the  risk  of  critical  aspects  of  the 
preferred  concept  alternative  and  improving  plans  for  the  development  of  the  system  specification. 

These  reviews  determine  whether  each  of  the  primary  system  functions  have  b^n  adequately 
addressed  to  surface  any  subsystem  issues  and  to  support  system  planning.  The  details  of  topics  to  be 


b. 
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reviewed  are  in  the  same  scope  as  those  identified  for  a  System  Requirements  Review  (SRR);  see 
Paragraph  5.9.3 .4 .3  of  Ref  (c)  in  Section  5,  above  for  more  details  on  the  SRR. 

This  is  the  final  scrub  of  the  details  that  are  developed  for  the  preferred  concept  alternative<s)  being 
proposed  for  the  next  phase  of  the  acquisition,  i.e.  Phase  1  -  Dem/Val.  Updates  and  content  iqsprovals 
tor  several  important  documents  are  included,  such  as  the  System  Engineering  Master  Plan  (SEMP), 
Test  and  Evaluation  Master  Plan  (TEMP),  Integrated  Logistics  Support  Plan  (ILSP),  Risk  Management 
Plan  (RMP),  etc.  Descriptions  of  these  and  additional  documentation  requir^  tor  the  MS  I  deceion  are 
given  in  ref  (a)  of  Section  5.  A  critical  item  to  be  refined  is  the  plans  tor  the  next  phase  that  address 
those  key  risk  areas  that  have  also  been  determined  to  be  critical  design  drivers.  Any  associated 
technolo^  development  areas  should  be  closely  tied  to  the  definition  of  the  risk  reduction,  with  options 
identified  as  backup  position(s).  The  Milestone  Decision  support  package  and  critical  shortfalls  should 
be  identified  and  Research  &  Development  requirements  established  for  Phase  1  efforts. 

8.  ENTRANCE/EXrr  CRITERIA; 

a.  Entrance;  This  activity  can  begin  either  during  or  after  the  complete  development  of  the 
preferred  alternative(s)  details. 

b.  Exit;  This  activity  concludes  when  it  has  been  verified  that  the  level  of  detail  is  sufficient  and 
consistent  for  the  altemative(s)  and  that  feasibility  formeeting  the  functional  and  system  requirements  is 
confirmed  by  the  Project  Cadre. 

9.  KEY  INPUTS  AND  OUTPUTS: 

Inputs; 

a.  From  D37B  -  Concept  Definition  for  Preferred  Alternative(s) 

(1)  System  details 

(2)  Life  Cycle  and  Design  to  Cost  Estimates 

(3)  System/Cost  Effectiveness  Analyses 

(4)  Survivability/Vulnerability  Estimates 

(5)  Supportability  Analyses 

b.  From  Cl  9  -  Develop  Draft  ORD  I 

(1)  Mission  Need  Statement  (MNS) 

(2)  Operational  Requirements  Document  (ORD)/Requirements  Correlation  Matrix(RCM) 

c.  From  BIO  &  Cl 6  -  Program  Management  Decision  (PMD) 

d.  From  D49  -  Updated  Database 

(1)  Trades/sensitivities  from  Preferred  Alternatives 

(2)  Enabling  Technologies  -  Advanced  Technology  Transition  Demonstrations(ATTD's) 

(3)  Performance  &  Effectiveness  Analyses 

(4)  Areas  of  Risk 

e.  From  C25  -  Select  Preferred  Attemative(s) 

(1)  Design  Constraints 

(2)  Lead  MAJCOM  Comments 


Outputs; 

a.  Primary  source  of  technical  details  tor  the  /ASP  Operational  Roundtable  (D67),  such  as; 
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(1)  up^es  to  following  documents:  SEMP,  SEMS,  SRD,  TEMP,  ILSP,  WBS, 
Manufacturing  Capability  Assessment.  Supportabdity  Analysis,  Maintenance  Plan,  Functional  Element 
Tree.  System  Specification  Outline,  RMP.  PPP.  Pollution  Preventbn  Action  Plan,  Integrated  Program 
Summary. 

(2)  “Changes”  to  Technical  Data. 

(3)  MNS  Satisfaction  Report. 

(4)  Outline  of  Technical  Exit  Criteria  for  Phase  I. 

(5)  Minutes  -  from  reviews  of  each  cortcept. 

b.  Source  of  data  for  updates  to  Cost  Analysis  Requirements  Descriptions  -  CARO.  (D72) 

10.  KEY  REFERENCES: 

Section  5.  Requirement(s)  plus: 

a.  AF  Sup  1/  0001 5000.2,  Acquisition  Management  Policies  &  Procedures.  Sep  92,  Part  2, 
Section  B,  Policies  for  interface  management. 

b.  MIL-K  IBK-499-3,  System  Engineering  /  Configuration  Management  (SE/CM)  -  Life  Cycle 
Application,  Ora  Aug  92,  Guidelines  for  system  reviews. 

c.  MIL-STO-1521 ,  Technical  Reviews  and  AudKs  for  Systems,  Equipments  and  Computer 
Software,  Appendix  A,  1988. 

d.  Systems  Engineering  Management  Guide,  DSMC,  Jan  91,  Identification  of  relevant  directives 
and  references  for  systems  engineering  corxrepts. 

•  e.  MIL-STD  1388-1A,  Logistics  Support  Analysis. 

f.  MIL-STD  1528,  Manufacturing  Management. 

g.  AFR  19-17,  Environment  Protection  Pollution  Prevention  Program. 

11.  IMPLEMENTATION  TOOLS: 

a.  System  Review  Outlines  from  Systems  Engineering  Management  Guide. 

b.  MIL-STD-499B,  Systems  Engineering,  Section  5  -  Detailed  Requirements  and  Appeixiix  C  - 
General  Guidance  on  the  Conduct  of  Technical  Reviews. 

c.  MIL-STD  1521,  Technical  Reviews  and  Audits  for  Systems,  Equipments,  and  Computer 
Software. 

12.  PLANNING  GUIDANCE:  This  review  may  be  accomplished  through  several  interim  reviews  and/or 
a  final,  overall,  system-level  review.  It  is  a  cooperative  activity  with  the  Project  Cadre  manager  having 
overall  responsibility  and  the  operating  MAJCOM  member  exercising  approval  authority. 

a.  DURATION:  Actual  review  of  3-4  days,  with  the  wrap-up  and  finalization  of  the 
documentation  and  system  summary  covering  an  additional  3-6  weeks  by  the  Project  Cadre. 

b.  CONSTRAINTS:  Availability  of  sufficiently  developed  detail  information  to  support  the 
system  component  and  configuration  item  (WBS  level  3  and  betow)  details  review. 
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c.  RESOURCES:  Entire  Project  Cadre;  potentially  requesting  consultation/advice  torm 
functional  area  “experts*:  SPD/PGM/MGM  members  particularly  important. 

d.  LESSONS  LEARNED: 

1 )  Incremental  reviews  can  be  more  efficient  and  effective. 

2)  Ensure  concept(s)  have  been  developed  in  comparable  detail  across  all  functional 

areas. 

3)  Specific  meeting  agendas  and  responsibilities  should  be  developed. 

4)  Build  and  maintain  options  in  the  design  and  implementation  of  complex  systems  for 
as  long  as  possible. 

e.  BEST  PRACTICES: 

1 )  Create  a  formal  operating  procedure  for  PARs. 

2)  Develop  an  acceptance  criteria  that  matches  the  defined  levels  of  success. 

f.  TRAPS:  The  most  serious  shortfalls  or  weaknesses  are  generally  'built-in'  due  to  the 
following  factors: 

1)  Ill-defined  purposes  with  poor  resource  allocation. 

2)  Inherently  conflicting,  but  unresolved,  priorities. 

3)  Poor  definition  of  the  success  or  acceptance  criteria. 

4)  Concept  designed  around  a  nonexistent  need  or  niche. 

5)  Too  little  consideration  to  reaction  of  the  threat. 
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1.  ELEMENT:  D46,  TBS  1 .2.3.4  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  Program  ANematives  Analysis  (PAA)  (It  is  irnponam  to  note  that  the  PAA 
is  not  a  practice  which  is  currently  in  place  at  any  of  the  product  centers.  This  entire  oorKept  is 
presented  as  an  opportunity  tor  improvement  even  though  H  is  described  here  as  an  existmg  event). 

3.  ELEMENT  OW»£R(S):  Recommend  this  process  be  AFMC/XR  at  the  HQ  Lev^  and  ASC/YX  at  the 
ASC  Level  (other  product  centers  need  to  identify  an  owner  in  their  organization  -  the  XRs  seem  Kke  the 
most  Kkely  candidates). 

4.  ELEMENT  STAKEHOLOER(S):  Virtually  everyone  involved  in  the  decision  making  process  for  a 
new  acquisition  below  the  Air  Staff  Level  is  a  stakeholder  in  this  process: 

•  ASC/XR 

•  Project/Program  Managers 

•  Key  Functional  Project/Program  Team  Members 

•  Program  Executive  Officers  (PEOs) 

•  Operational  Users  (both  the  operators  and  the  maintainers) 

5.  REQUIREMENT:  Essential  to  any  effort  attempting  to  pursue  good  business  practices.  Recommend 
ASC/YX,  in  conjunction  with  AFMC/XR,  develop  a  guide  similar  to  that  developed  by  ASC/CYX  for  the 
RFP  preparation.  This  process  would  also  need  to  be  included  in  the  lASP  process  already  owned  by 
AFMC/XR. 

6.  PURPOSE  AND  OBJECTIVES: 

a.  Purpose:  The  purpose  for  including  this  process  is  to  ensure  that  the  business,  financial,  and 
political  risks  are  examined  for  each  concept  being  considered  during  Concept  Exploration.  The 
following  statements  summarize  the  purpose  for  corKkJCting  the  Program  Alternatives  Analysis: 

1)  Characterize  Program  Risks  for  Each  Alternative  Under  CJonsideration 

2)  Match  'Program  Development  Options  with  Alternatives 

3)  Provide  User  Insight  into  Program  Development  Impacts 

b.  Objectives:  There  are  three  main  objectives: 

1 )  Ensure  the  concept  or  concepts  which  are  chosen  to  go  forward  into  the  second  half  of 
Phase  0,  Concept  Definition,  are  selected  based  on  overall  programmatic  risk  (to  include  technical  risk) 
rather  than  purely  technical  risk.  This  should  produce  an  overall  project/program  package  which  is  far 
more  executable  than  one  based  solely  on  its  technical  prowess. 

2)  Present  the  User  and  the  Development  communities  with  some  realistic 
programmatic  expectations  for  the  concepts  being  considered. 

3)  An  objective  is  ggLto  stifle  industries'  creativity  in  any  way.  Each  of  the  concepts 
presented  through  the  trs^e  studies  needs  to  be  considered.  Innovative  new  designs  and  concepts  may 
require  correspondirrg  inrxwative  new  business  practices. 
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7.  DESCRIPTION: 


Proposed  Improvement  to  Phase 


Operating  from  the  age  old  axiom  that  ’a  picture  is  worth  a  thousand  words,*  this  simple  chart  is  provided 
in  an  attempt  to  cut  down  on  the  text.  This  top-level  illustrative  example  is  a  suggestion  on  how  we  oould 
improve  the  existing  Phase  0  process.  A  number  of  the  activities  haw  been  shuffled  around  or  moved 
earlier  in  the  process  to  allow  for  the  earlier  oonsiderations  of  the  programmatic  constraints.  By  doing 
this,  these  oonsideratiorts  should  provide  some  leverage  in  the  selection  of  the  preferred  concept. 
Provided  below  is  a  brief  description  of  the  new  bloclts  to  show  how  this  propo^  process  wouldwotk. 

-  Summit  I  -  There  is  currently  no  such  activity  this  early  in  Phase  0.  The  goal  of  the  summit  is 
to  provide  top-down  (Erection  as  to  the  need  and  the  initiai  requirements.  This  wil  prevent  the  Strategic 
Roundtable  from  turning  into  a  requirements  summit  and  allow  them  to  focus  on  providing  strategic 
guidance  to  the  project  leader.  The  Summit  I  should  consider  the  analysis  work  accomplished  Pr^ 
Milestone  0  as  well  as  the  more  detaled  analysis  accomplished  in  the  first  round  of  Concept  Exploration 
(CE),  comments  from  the  JROC,  and  inooqsorate  the  direction  provided  by  the  Milestone  0  Acquisition 
Decision  Memorandum  (ADM)  and  the  Program  Management  Directive  (PMD).  The  direction  from  this 
activity  needs  to  feed  diiectiy  into  the  Strategic  Roundtable. 


-  Program  Akematives  Analyse  I  (PAA I)  -  This  e  the  second  key  input  necessary  tor  the 
Strategy  Roundtable  to  provide  broad  ba^  programmatic  strategic  guidance.  The  input  would  define 
(to  the  limits  reaKsticaHy  possUe  at  the  early  point  in  the  project)  the; 

-  Resources  required  to  pursue  each  of  ttte  conr^s  being  considered.  To  include 
manpower,  facilities,  and  dollars. 

-  Industrial  base  cortsiderations  (or  each  concept. 

-  Possible  program  risks  for  each  concept.  To  include  schedule,  financial,  and  political 
which  might  irwolve  competirtg  with  existirrg  programs. 

-  Best  Business  Practices  and  their  appUcability  to  each  of  the  potential  concepts. 

-  Technical  Risks  as  determined  through  Concept  Exploration. 

In  short,  this  is  an  analysis  of  potential  problems  a  program  might  encounter  for  each  of  the  cortcepts 
under  review.  The  development  community  has  generally  done  a  fairly  good  job  defining  the  tectmical 
risk  involved  in  a  new  concept;  the  shortfall  has  been  in  defining  the  numerous  other  risks  which  the 
project/program  team  will  encounter  as  they  execute  their  acquisition. 

■  Program  Alternatives  Analysis  II  (PAA  II)  --  This  is  a  repeat  performance  of  the  PAA  I  at  a 
higher  level  of  refinement.  The  output  of  this  session  win  be  to  the  Tactical  Roundtable  for  the 
development  of  the  Acquisition  Strategy  for  each  of  the  concepts  being  forwarded  for  comparative 
analysis.  This  will  allow  the  user  to  base  his  Preferred  Concept  Selection  decision  (IFC  bik  #C25)  on 
more  than  just  the  technical  merit  and  cost  estimate  for  each  of  the  cortcepts.  The  users  decision  will  be 
based  on  Mh  of  these  factors  and  a  'big  picture*  program  executability  analysis  for  each  of  the 
concepts. 

-  lASP  -  The  only  real  change  in  the  lASP  is  that  the  entire  process  is  TTX>ved  much  earlier  in  the 
concept  exploration  process.  As  it  exists  today,  the  Strategic  Roundtable  doesn't  even  convene  until 
after  all  the  technical  analysis  activities  are  basically  complete,  the  COEA  is  complete,  and  the  ORD  has 
been  written.  The  way  the  lASP  is  being  used  today  is  to  properly  package  what  has  already 
accomplished  in  order  to  present  the  project  story  to  the  Milestone  Decision  Authority  (MDA).  This  is  an 
extremely  important  task,  but  does  not  take  full  advantage  of  the  experience  and  brain  power  sitting 
around  the  table.  By  moving  the  lASP  earlier  in  the  concept  exploration  process  arxf  providing  them  with 
top^lown  direction  from  the  Summit  I  and  bottoms-up  inputs  from  the  Ck>ncept  Exploration  activities 
regardirrg  technical  risk  as  well  as  a  PAA  look  at  the  programmatic  risks  which  might  be  encountered 
with  each  of  the  concepts  under  consideration,  the  Strategic  Roundtable  has  been  equipped  with  the 
tools  necessary  to  perform  their  tasking  -  make  informed  up-front  acquisition  strategy  decisions(lFC  bIk 
#D57). 

8.  ENTRANCeEXIT  CRITERIA: 

a.  Entrance  into  this  process  would  be  possible  when  the  development  community  receives  the 
Milestone  0  PMD  (IFC  bik  #  BIO).  You  will  also  be  able  to  adequately  understand  the  need  and  have 
some  initial  ideas  to  the  top-level  requirements  (IFC  bik  #  D23). 

b.  Exit  criteria  for  the  overall  process  as  described  above  have  been  met  when  you  have 
assembled  a  data  package  describing  an  executable  program  which  identifies  the  technica),  financial. 
programmatic,  and  politicai  risks  involved  with  committing  to  a  new  start  on  a  given  corKept  and  offers  a 
set  of  potential  methods  for  dealing  with  these  risks. 

9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Key  inputs  would  include; 

-  Milestone  0  Acquisition  Decision  Memorandum  (ADM)  (IFC  bik  #A09)  and  the  Program 
Management  Directive  (PMO)(IFC  bik  #B10). 

-  Assessment  from  the  Concept  Exploration  activities  (CE)  (IFC  Wk  #D37). 
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•  Updated  version  o<  the  Phase  0  (IFC  bik  «  D22)  plan  which  will  inchjde  revisions  based 
on  the  MieMone  0  DAB  (via  the  AOM  and  PMO)  and  any  redirection  or  fex:using  by  the  Concept 
Action  Group  (CAG  •  if  this  group  is  being  used)  (IFC  tik  «  C16). 

-  Minutes  from  the  Altemative  Systems  Review  (ASR)  (IFC  blr  #  045) 

-  Feedback  to  and  from  the  Cost  and  Operational  Effectiveness  Analysis  (COEA) 
activities  (IFC  bIk  #D48)  which  are  being  conducted  concurrently  with  the  Pr^am  AHematives 
Analysis. 

b.  The  key  outputs  would  be: 

-  Preliminary  Project  Office  Cost  Estimate  (IFC  bk  #047). 

-  Recommendations  from  the  Program  Alternatives  Analysis  I  and  II  should  be  included 
in  the  i^xfated  project  data  base  (IFC  bl(  #049). 

-  Recommendatiorts  from  the  Program  Alternatives  Analysis  I  would  also  be  the  basis 
tor  developing  the  Preliminary  Acquisition  Strategy  Report  (ASR)  (IFC  bik  #  D58). 

-  Notes  from  PAA I  wiH  be  a  primary  input  to  the  Strategic  Roundtable  (IFC  bk  #  D57). 

•  Recommendations  from  the  Program  Alternatives  Analysis  II  would  be  the  basis  tor 
developing; 

-  Initial  program  Cost  and  Schedule  effectives  at  the  Tactical  Roundtable 

(IFC  bk  #059). 

-  Acquisition  Strategy  Report  (ASR)  (IFC  Mr  #  060). 

-  The  notes  from  these  sessions  (particularly  PAA  II)  would  be  a  critical 
input  for  the  User  to  make  his  Preferred  Altemative  Selection  (IFC  bik  #  C25). 

10.  KEY  REFERENCES: 

Since  this  activity  is  being  presented  as  a  suggested  improvement  to  the  Phase  0  flow  of  activities,  there 
are  no  real  references.  However,  the  Program  Alternatives  Analysis  is  in  keeping  with  the  general 
pNlosophy  of  the  following  sources; 

-  OoOl  5000.2,  Change  1 , 10  Mar  93. 

•  OoO  5000.2  Manual,  Change  1,10  Mar  93. 

-  AFMC  Pamphlet  800-7,  Integrated  Acquisition  Strategy  Process  .  20  Nov  92 

11.  IMPLEMENTATION  TOOLS:  ASC/YX  Flowchart  and  this  data  sheet. 

12.  PLANNING  GUIDANCE: 

A)  DURATION:  The  time  required  to  conduct  the  Program  Alternatives  Analysis  I  will 

vary  greatly  depending  on  the  number  of  concepts  being  considered.  For  most  major  potential  new 
starts,  plan  on  a  week-long  working  group.  For  Program  Alternatives  Analysis  II,  the  concepts  would 
likely  be  fewer  but  the  level  of  detail  would  be  greater.. .plan  on  another  w^-long  session. 

B)  CONSTRAINTS:  The  PAA  is  not  a  recognized  event.  The  primary  constraint  will  be  in 
convindr^  the  user  and  development  communities  of  the  value  added  in  considering  programmatic  risks 
eatly-on  in  the  Phase  0  process. 

C)  RESOURCES:  The  only  resources  required  would  be  persons  knowledgeable  in 
programmatic  risks  areas.  ASC/YX  would  be  an  excellent  first  step  in  putting  together  your  PAA  team. 

D)  LESSONS  LEARNED:  There  has  never  been  a  formal  PAA;  however,  there  are  hundreds  of 
examples  of  the  hazards  involved  with  basing  your  concept  selection  on  purely  technical  risks  and  failing 
to  consider  programmatic  risks  early  in  the  Phase  0  process. 
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E)  BEST  PRACTICES:  Accomplishing  a  PAA  is  in  UseH  a  best  practice. 

F)  TRAPS:  If  you  see  your  program  requirements  starting  to  gravitate  towards  the  *brightest 
and  shiniest*  new  tectmology  on  the  market,  beware!  It  will  be  a  very  rare  case  when  a  totally  new 
technology  is  the  goix  possible  solution  to  a  given  need.  This  new  t^nology  may  be  the  100%  solution, 
but  consider  whether  the  answer  to  the  user's  bona  fide  need  would  be  better  served  by  pursuing  an 
80%  solution  that  has  greatly  reduced  and  manage^e  technical  and  programmatic  risk. 
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1.  ELEMENT:  D47.  TBS  1 .2.3.6  (IFC  93-3) 

2.  ELEMENT  TITLE:  Update  Program  Cost  Estimate 

3.  ELEIIENT  OWNER:  ASC/FM 

4.  ELEMENT  STAKEHOLOER(S):  Hq  USAF,  Operating  Command,  Program  Element  Monitor 
(PEM),  Project  Team,  ASC/AL. 

5.  REQUIREMENT:  ASOR  173-1,  Aeroruiutical  Systems  Division  Cost  Attalysis  Program,  17  Jan 
89,  defines  the  cost  estimating  responsibilities  and  requirements  for  project/program  offices  at 
ASC,  and  provides  comprehensive  guidance  on  estimate  documentation.  The  requirements 
remain  the  same,  regardless  of  ACAT  level. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  activity  is  to  generate  and  document  an  estimate  of  the 
financial  requirements  of  the  anticipated  program. 

b.  Objective:  The  objective  of  documenting  a  program  estimate  at  this  time  is  to  support 
the  budget  process  -  if  there  is  an  opportunity  to  submit  a  budgetary  wedge  for  the  anticipated 
program  in  the  Air  Force  Program  Objective  Memorandum  (POM),  this  estimate  documentation 
would  serve  as  the  basis  for  the  budget  submission.  The  documentation  would  also  be  utilized  to 
support  any  budget  or  cost  analysis  reviews  by  the  Operating  Command.  Further,  the 
documentation  could  be  utilized  as  a  preliminary  tool  to  summarize  programmatic  information  on 
the  anticipated  program  prior  to  completion  of  the  Cost  and  Operational  Effectiveness  Analyses 
(COEA)  and  selection  of  the  recommended  program  alternative.  The  scope  of  the  estimate  should 
be  as  complete  as  possible,  and  address  all  life  cycle  costs  of  the  program.  However,  at  this 
phase  of  the  project,  it  may  only  be  possible  to  estimate  the  program  requirements  that  can  be 
included  in  the  POM  -  only  limited  content  and  fiscal  years. 

7.  DESCRIPTION:  The  development  of  this  cost  estimate  can  be  grouped  into  five  major 
activities  which  are  summarized  below.  The  reader  will  find  a  description  of  these  tasks  in  Chapter 
3,  Vol.  1  of  the  refererKed  AFSC  Cost  Estimating  Handbook.  In  addition,  more  detail  is  provided 
in  other  chapters  of  the  handbook  as  noted: 

a.  Defining  the  estimate  -  this  effort  consists  of  defining  the  program  to  be  estimated, 
determining  the  scope  of  the  estimate,  assembling  the  estimating  team  and  assigning 
responsibilities,  and  defining  estimate  grourxfrules,  assurr^ions.  and  constraints.  The  estimating 
team  should  consist  of  the  cost  analysts  and  all  functional  support  personnel  identified  to  support 
the  estimating  effort.  This  should  be  documented  in  the  estimate  plan,  and  approved  by  the 
project  manager.  The  estimate  plan  should  contain  a  schedule  for  the  estimating  activities  based 
on  the  estimated  time  required  to  accomplish  the  following  estimating  tasks.  The  time  required  for 
each  of  the  activities  can  be  expected  to  vary  for  every  estimate,  depending  on  the  size  and 
experience  level  of  the  team,  prior  research  and  estimating  efforts  for  the  program,  etc.  Specific 
sources  of  information  which  should  help  define  the  program  to  be  estimated  are  contained  in  Key 
Inputs  (Section  9.a.),  which  follows  (Chapter  4). 

b.  Research  -  the  cost  analysts  perform  initial  research  to  determine  appropriate 
estimating  methodologies,  and  perform  data  collection  to  determine  if  information  can  be  obtained 
to  support  the  selected  estimating  approach(es)  (Chapter  5). 

c.  Develop  the  estimating  approach  -  the  preliminary  estimating  methods  are  selected, 
and  any  estimating  tools  are  designed  or  updated,  as  appropriate  (Chapter  6). 
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d.  Perform  estimate  aiKf  crosschecks  -  the  ariaiysts  generate  the  detailed  estimates  and 
verify  the  results  with  any  appropriate  crosschecks  to  ensure  the  results  are  logical,  reasonable, 
and  complete.  (Note:  An  estimate  documented  to  support  either  a  milestone  review  or  a  budget 
submission  must  reflect  a  ‘poirtt  estimate.*  However,  if  possible,  the  estimators  should  provide 
estimate  ranges  to  the  decision  makers  to  aid  in  the  esttfnate  review  and  approval  process] 
(Chapter  4,  Paragraph  4.5.3.). 

e.  Documentation  and  approval  -  the  estimate  must  be  documented  and  provided  to 
project  management  for  approval.  This  process  usually  irtvolves  presentation  of  the  estimate  to 
the  senior  program  and  functional  managers  assigned  to  the  proj^.  After  approval,  the  estimate 
becomes  the  official  program  estimate,  and  should  be  the  basis  for  aH  program  estimate  ‘what  ifs* 
and  budget  stdtmissions  until  superseded  by  another  formal  program  estimate.  The  reader  should 
refer  to  Chapter  22,  of  the  referenced  AFMC  Cost  Estimating  Handbook,  or  ASDR  173-1  for  more 
detailed  information  on  ASC  estimate  documentation  requirements. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  need  for  an  estimate  of  program  costs  at  this  point  should  be  dependent 
on  the  ability  to  interject  the  estimated  program  costs  into  the  Air  Force  Program  Objective 
Memorandum  (POM)  to  establish  a  preliminary  financial  position  for  the  anticipated  program.  The 
POM  submission  will  only  address  the  years  in  the  Future  Year  Defense  Program,  and  the  program 
may  not  have  any  activity  in  those  years.  If  it  is  not  expected  that  the  estimate  can  be  utilized  for 
the  POM,  formal  estimating  activity  may  be  deferred  until  the  COEA  analysis  is  performed,  and  the 
preferred  program  option  has  been  determined.  However,  the  cost  analyst  should  begin  collecting 
data  and  planning  formal  estimating  activities  at  this  time. 

b.  Exit:  If  the  estimate  is  to  be  submitted  for  inclusion  into  the  POM,  it  must  first  be 
reviewed  and  approved  by  the  project  manager  and  the  project  OPR  in  the  Operating  Command. 
For  discussion  purposes,  it  is  assumed  that  this  will  be  the  Corx:ept  Action  Group  (CAG)  in  the 
Operating  Command  (Cl 6).  Note:  The  formal  estimate  discussed  here  should  not  be  confused 
with  the  normal,  almost  continuous  cost  analysis  and  estimating  that  is  performed  in  a  project 
office.  However,  whether  a  'what-if*  or  formal  estimate,  the  estimates  should  be  documented, 
tracked,  and  archived  as  part  of  the  project  database. 

9.  KEY  INPUTS/OUTPUTS: 

a.  Inputs:  At  this  stage  of  the  project,  typically  only  minimal  technical  and  programmatic 
information  is  available.  However,  to  derive  even  a  top  level  estimate  of  potential  costs,  the 
project  team  must  develop  a  minimal  program  framework  which  can  be  priced  out.  Necessary 
information  would  include  system  description  (to  the  extent  possible),  development  and  production 
schedules,  quantities,  and  acquisKion  strategy.  The  source  of  this  information  would  be  functional 
(engineering,  manufacturing,  contracts,  logistics,  test  and  management  personnel)  and  the 
Operating  Command  j^ersonnel.  In  addition  to  providing  detailed  information  on  their  functional 
areas,  these  experts  will  need  to  supjxrt  the  cost  estimators  by  identifying  analogous  programs, 
and  aiding  in  the  development  and  justification  of  the  selected  estimating  relationships.  The 
results  of  the  Concept  Exploration  Studies  (D37),  COEA  Comparative  Analysis  (D48),  Program 
Alternatives  Analysis  (D46),  and  the  updates  to  the  Program  Database  (D49)  should  provide 
information  on  potential  program  alternatives.  This  information  should  be  useful  in  providing 
necessary  program  information  which  would  support  program  definition  for  the  purpose  of 
developing  this  cost  estimate. 

b.  Output:  The  results  of  the  analysis  should  be  formally  documented  and  approved  by 
the  project  manager  and  archived  in  the  project  database.  The  documentation  should  include  all 
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groundailes  and  assumptions  and  programmatic  information  necessary  to  reptic^e  the  estimate 
and  fully  support  cost  relationships  utilized.  If  the  estimate  will  be  utilized  to  support  a  budget 
submission,  the  documentation  should  be  accomplished  in  accordance  with  ASDR  173-1 .  The 
results  of  the  analysis  can  be  used  by  the  Operating  Command  to  support  the  preferred 
altemative<s)  selection  (C25).  and  to  update  the  project  budget  requests  (C22). 

c.  Foitow-on  activities:  If  the  estimate  is  to  be  included  in  the  Air  Force  POM,  it  will  need 
to  be  provided  to  the  Operating  Command  Concept  Action  Group  (CAG)  for  review  and  approval, 
prior  to  the  submission  in  the  POM  process.  Historically,  the  POM  call  to  AFMC  organizations  is  in 
the  summer  of  each  odd-numbered  year.  To  satisfy  this  schedule,  the  project  team  should  plan  to 
have  the  estimate  completed,  and  approved  by  the  CAG  by  the  erxj  of  May.  The  estimate  can 
then  be  irxnrporated  into  the  field  POM  submission  to  the  Operating  Command,  or  the  CAG  may 
input  and  support  the  estimate  during  the  Operating  Command  POM  review.  The  estimate  should 
then  be  included  in  the  Operating  Command  POM  submission  to  USAF.  If  approved,  the  estimate 
would  be  included  in  the  Service  (Air  Force)  POM  submission  to  OSD,  usually  in  April  of  the  even- 
numbered  years.  The  inclusion  of  the  estimate  into  the  Air  Force  POM  is  critical  in  that  it  is  the  first 
step  in  identifying  and  programming  financial  requirements  in  the  budget  process.  If  the  estimate 
is  not  approv^  and  converted  into  budgetary  requirements  lead  time  away  from  the  required  time 
for  the  funding,  the  project  will  incur  schedule  delays  until  funds  are  available. 

10.  KEY  REFERENCES: 

a.  AFR  173-1 ,  Th«  Air  Force  Cost  Analysis  Program,  3  Oct  80  -  Establishes  the  Air  Force 
Cost  Analysis  Program,  specifies  objectives  and  functions,  and  assigns  respons^lities. 

b.  AFR  173-1 1 ,  Independent  Cost  Analysis  Program.  7  Oct  86  -  Identifies  requirements  for 
Indeperxjent  Cost  Analysis  and  Program  Office  Estimates. 

c.  AF  Sup.  1/DoDI  5000.2,  Aug  92  (DRAFT),  Part  10A  -  Air  Force  cost  estimating 
requirements. 

d.  AF  Instruction  10-601 .  Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,  16  Feb  93,  paragraphs  1 .3.10, 1 .4,  Attachments  1 , 2,  and  5  -  Provides  guidarce  on 
the  CAG  and  COEA. 

11.  IMPLEMENTATION  TOOLS:  ASC/FM  can  provide  information  on  the  foibwing  cost  analysis 
aids  and  tools; 

a.  The  AFSC  Cost  Estimating  Handbook.  Vol  I  (undated)  -  estimating  and  documentation 
informatbn. 

b.  The  AFSC  Financial  Management  Handbook.  Nov  92  update-  financial  informatbn. 

c.  The  ASC/FM  Cost  Workstation  -  a  computer  autorriation  ab  and  appibation  tool. 

d.  ASC  Cost  Data  Center  -  historical  cost  data,  cost  models,  and  other  cost  related 
materials  and  references. 

e.  AFMC  Cost  Estimating  Handbook.  Vol.  II,  Aeronautbal,  21  Sep  92  -  estimating  and 
documentation  informatbn. 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  time  required  to  perform  and  document  an  estimate  must  be 
planned  based  on  the  specific  conditions  and  methodologies  chosen.  The  time  can  be  expected  to 
vary  for  every  estimate  depending  on  the  program  complexity,  data  availability,  and  the  size  and 
experience  level  of  the  estimating  team.  Early  in  the  program  life  cycle,  estimating  activities  are 
typically  based  on  parametric  analysis  and  should  take  2  to  4  months.  Again,  this  cani  be 
considered  firm;  the  time  required  to  perform  and  document  an  estimate  must  be  planned  based 
on  the  specific  conditions  and  methodologies  chosen. 

b.  CONSTRAINTS:  The  greatest  limitations  in  the  performance  of  the  estimate  are  lack 
of  program  definition,  and  the  lack  of  relatable  historical  cost  information.  If  sufficient  personnel 
areni  assigned  to  accomplish  the  analysis  in  time  to  meet  the  required  schedule,  support  should 
be  requested  from  staff  home  offices  or  the  Program  Development  SPO  (ASC/YX). 

c.  RESOURCES:  The  estimate  is  usually  perfonned  by  one  or  two  cost  estimators, 
working  the  estimate  as  a  primary  duty.  Operating  and  Support  cost  estimating  support  from 
ASC/AL  may  also  be  required  if  the  project  office  does  not  have  the  in-house  capability  to  perform 
this  analysis.  Engineering,  logistics,  test,  and  program  management  personnel  should  be  formally 
assigned  to  the  team,  even  if  dedicated  only  part  time,  and  they  can  be  expected  to  need  to 
provide  40  -  80  hours  each  for  technical  support.  Computer  assets  should  be  considered  a 
necessity  for  both  estimate  computation  and  documentation. 

d.  LESSONS  LEARNED:  The  Cost  Staff  (ASC/FMC)  should  be  contacted  to  have  a  staff 
cost  analyst  focal  point  assigned  to  support  the  analysis  effort.  This  analyst  will  be  a  valuable 
resource  in  aiding  in  data  searches  arfo  estimating  methodology  selection.  The  analyst  can  be  a 
valuable  asset  in  supporting  management  reviews.  Further,  the  cost  staff  may  be  able  to  provide 
analysts  to  perform  elements  of  the  estimate  or  to  perform  schedule  analysis.  It  should  be 
expected  that  many  program  variations  and  estimating  excursions  will  be  performed  to  support  the 
decision  making  process  and  each  of  these  should  be  documented  and  tracked  by  both  program 
content  and  estimate  results.  Failure  to  do  so  could  result  in  significant  rework  and  loss  of 
credibility.  This  estimate  should  provide  an  estimating  baseline  -  formal  estimates  which  follow 
this  analysis  should  contain  a  track  to  this  estimate,  including  rationale  for  changes. 

e.  BEST  PRACTICES:  The  cost  analyst  should  develop  a  comprehensive  estimate  plan 
which  defines  program  content,  describes  the  estimating  approach  and  the  estimate  schedule, 
identifies  estimate  team  members  and  assigns  responsibilities,  and  identifies  estimate  groundrules 
and  assumptions.  The  management  approval  of  this  plan  should  ensure  the  commitment  of 
necessary  resources,  and  baseline  the  program  to  be  estimated.  Lack  of  a  comprehensive  plan 
may  result  in  unnecessary  perturbations,  rework,  and  schedule  slips. 

f.  TRAPS:  It  is  imperative  that  the  cost  analysts  identify  methodologies  and  data 
requirements  as  soon  as  possible  so  that  these  needs  can  be  made  known.  If  this  information  is 
not  available,  work-arounds  must  be  made  as  soon  as  possible  to  maintain  the  estimatirrg  schedule 
and  support  the  POM  input  schedule.  Also,  it  is  essential  that  the  estimating  and  functional  team 
members  be  carefully  selected,  so  that  all  information  necessary  to  support  the  estimating  process 
can  be  provided  in  a  timely  manner. 
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1.  ELEMENT:  D48,  TBS  1 .2.3.3  (IFC93-3) 

2.  ELEMENT  TITLE:  Conduct  Cost  and  Operational  Effectiveness  (COEA)  Comparative  Analysis 

3.  ELEMENT  OWNER:  Operating  Command 

4.  ELEMENT  STAKEHOLOER(S): 

Aeronautical  Systems  Center  (ASC)/YX 
Product  Centers/XR/Functionals 

ASC/System  program  offices  if  they  are  impacted  by  the  project  or  if  they  will  inherit  the  program 
at  Milestone  l/IV 

Air  logistics  centers  impacted  by  the  potential  program 
Headquarters  (HQ)  Air  Force  Materiel  Command  (AFMC) 

Air  Education  and  Training  Command  (AETC) 

HQ  USAF  and  department  of  defense  offices  that  will  review  COEA  I  report  during  the 
Milestone  I  decision  process.  Some  of  these  are; 

OSD/PA&E 

Defense  Acquisition  Board  (DAB) 

Defense  Intelligence  Agency 

Secretary  of  the  Air  Force  (SAF)/AQ/FMC 

HQ  USAF/XOR/XOW/SC/TE 

Air  Force  Intelligence  Support  Agency 

Air  Force  Operational  Test  and  Evaluation  Center 

Air  Force  Studies  and  Analysis  Agency 

5.  REQUIREMENT :  DoDI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures.  Part  4, 
Section  E  and  Part  1 1 ,  Section  C,  Attachments  1  and  2,  23  Feb  91 .  Part  4  provides  the  policies  and 
procedures  to  establish  the  basis  for  developing  cost  and  operational  effectiveness  analyses  to  support 
milestone  decision  reviews  while  Part  1 1  identifies  ao^isition  categories  (ACAT)  I  -  4  COE/, 
requirements. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  Provide  the  operating  command  with  information  to  justify  and  select  a  preferred 
alternative  and  provide  an  analytical  basis  to  support  the  acquisition  Milestone  I  decision  review. 

b.  Objectives:  Provide  information  to  determine  whether  a  new  program  is  warranted  and,  if  so, 
to  identify  key  performance  parameters.  The  full  range  of  materiel  alternatives  must  be  considered. 
These  alternatives  may  include  the  current  system,  a  modified  current  system,  programmed  Air  Force 
systems,  other  services'  systems  (existing  or  programmed),  nondevelopmental  items,  cooperative 
(allied)  developmental  systems,  and  new  concepts.  This  comparative  analysis  should  help  limit  the 
number  of  alternatives  considered  during  Phase  I.  The  Milestone  I  COEA  determines  the  operational 
effectiveness  and  life  cycle  costs  (LCC)  (including  estimates  of  training  and  logistics  impacts)  for  viable 
alternatives,  including  directed  operational  and  support  concepts  from  Milestone  0  decision;  identifies 
key  performance  parameters  for  the  preferred  altemative(s)  concept  baseline;  and  indicates  how  these 
critical  parameters  impact  operational  and  support  capability,  readiness,  and  cost.  The  analysis  also 
identifies  opportunities  for  trade-offs  among  performance,  cost,  and  schedule  and  supports  development 
of  the  operational  requirements  document  (ORD)  and  the  decision  as  to  which  materiel  altemative(s) 
satisfies  the  ORD.  Additionally,  sensitivity  analysis  is  done  on  all  constraints,  such  as  operational  arid 
support  assumptions,  to  determine  the  best  preferred  altemative(s). 
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7.  DESCRIPTION: 

a.  The  first  arxl  foremost  fact  the  project  team  must  remember  is  that  the  operating  command  is 

the  owner  and  customer.  Thus,  the  comparative  analysis  should  meet  their  objectives  and  comply  with  ^ 

the  framewoi1(  that  the  acquisition  decision  memorandum  (ADM),  program  management  directive 

(PMD),  OSD/PA&E,  and  operating  command  establish.  The  prc^  team  must  also  openly  advise  the 

user  of  options,  regulatory  requirements,  best  practices  and  lessons  learned  so  the  operating  command 

can  achieve  their  objectives.  The  comparative  analysis  includes  many  preceding,  on-going,  and  iterative 

activities  of  the  entire  Phase  0; 

» 

1 .  Reviewing  and  approving  COEA  I,  C1 7. 

2.  Developing  a  draft  ORD  I.  C19. 

3.  Selecting  the  COEA  I  concepts,  C21 . 

4.  Selecting  the  preferred  alternative,  C25. 

5.  Updating  database,  D44  &  49. 

6.  CoTKlucting  program  alternatives  analysis.  D46.  * 

b.  The  Operating  Command  concept  action  group  (CAG)  or  study  group  oversees  the  entire 
COEA  effort  irK:luding  developing  a  COEA  I  study  plan.  The  comparative  analysis  must  follow  the 
guidance  in  the  COEA  I  study  plan,  C17.  Pay  particular  attention  to  the  following  addressed  in  the  COEA 

I  study  plan  to  ensure  the  analyses  are  conducted  objectively  and  address  Milestone  0  taskings:  ^ 

1.  Study  Plan  Acquisition  Issues 

a.  Mission  Need;  The  analysis  must  be  consistent  with  the  approved  mission 

need  statement  (MNS). 


b.  Threat;  Consistent  with  the  defense  planning  guidance  (DPG)  and  threat  in 
the  MNS,  other  various  intelligence  documents  [System  Threat  Assessment  Report  for  acquisition 
category  I  or  System  Threat  Assessment  for  ACAT  It,  III,  and  IV],  and  all  other  documents  being 
prepared  for  Milestone  I  decision. 

c.  Environment;  Same  as  for  Threat.  Explicitly  include  potential  contributions 

of  allied  forces. 


d.  Constraints  and  Assumptions;  Same  as  for  Threat.  Some  critical  constraints 
could  be  manpower  to  operate  and  support  the  system  concepts;  specifics  of  the  operational  and 
maintenance  concepts;  funding  for  development,  procurement,  and  operation  and  support  (O&S); 
technology;  security;  special  access;  projected  lot  buys  and  total  buys;  and  projected  force  stnjcture.  In 
a  very  real  sense,  there  are  few  ’hard,  unchallengeable”  requirements  in  weapons  acquisition.  Certain 
characteristics,  capabilities,  and  levels  of  effectiveness  are  not  ’essential,  regardless  of  cost.’  Sensitivity 
analysis  illuminates  how  important  it  is  to  incorporate  these  features  into  a  system. 

e.  Scenarios;  Same  as  for  Threat.  Scenarios  draw  upon  the  need,  threat 
estimates,  operational  concepts,  environment,  and  constraints.  They  must  be  consistent  across  the 
various  concerns  and  will  cornply  with  the  DPG. 

2.  Study  Plan  Analysis  Approach 

a.  Methodology;  Use  the  simplest  possible  methodology  and  only  accepted 
[Cost  Analysis  Improyement  Group  (CAIG)  approyed]  cost  models  for  the  analysis. 
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b.  Effectiveness  Analysis  (The  three  effectiveness  measures  Hsted  below  should 
be  specified  prior  to  doing  the  actual  comparative  analysis.  This  ensures  objectivity.  Ooni  select  the 
measures  to  get  the  answer  someone  wants); 

c.  Functional  Objectives:  DoD  5000.2-M  defines  functional  objectives  as 
statements  describing,  in  quantitative  terms,  the  tasks  a  system  will  be  expected  to  perform.  The 
effectiveness  of  system  alternatives  is  then  measured  in  terms  of  the  degree  to  which  the  fcjnctional 
objectives  would  be  attained.  AFMCP  173-1  defines  functional  objectives  as  goals  that  the  system  wilt 
be  expected  to  meet.  They  act  as  the  standards  for  comparing  alternatives.  (An  example  of  a  functional 
objective  is  the  capability  of  a  new  weapon  system  to  attack  an  XYZ  target  type  arxj  achieve  a  firepower 
kill.) 

d.  Measures  of  Effectiveness  (MOE):  MOEs  are  tools  that  assist  in 
discriminating  among  a  number  of  alternatives.  They  show  how  the  alternatives  compare  in  meeting 
functional  objectives.  They  are  measures  at  a  high  level  versus  measures  of  performance  (MOP). 

MOEs  should  relate  as  directly  as  possible  to  system  functional  objectives  and  to  miscon 
accomplishment.  MOEs  should  be  defined  to  measure  operational  capabilities  in  terms  of  engagement 
or  battle  outcomes.  Show  how  the  MOEs  are  derived  from  the  MNS.  The  MOEs  and  related  MOPs 
should  be  included  in  the  ORD  and  the  key  MOEs/MOPs  from  the  ORD  should  also  be  included  in  the 
acquisition  program  baseline  (APB)  and  TEMP  subject  to  review  by  the  requirements  validation  authority 
and  approval  by  the  milestone  decision  authority  (MDA).  MOEs  can  bias  the  analytical  outcome;  their 
selection  requires  rigorous  attention.  Generally,  the  more  MOEs,  the  better  the  analysis.  Ensure  MOEs 
exist  tor  each  functional  objective.  (Continuing  the  above  example,  a  MOE  example  is  the  probability  of 
achievirrg  a  firepower  kill  on  the  XYZ  target.) 

e.  Measures  of  Performance;  MOPs  measure  system  operational  performance 
in  terms  of  system  capability.  They  should  state  exactly  what  system  pertonname  characteristics  are  to 
be  measured,  e.g.,  specification  items  as  range,  speed,  payload,  and  radar  cross  section. 

f.  Life  Cycle  Cost  (LCC)  Analysis:  Consider  acquisition  costs  (ir»j;.jding 
manpower),  O&S  costs,  disposal  and  military  construction  costs  for  each  alternative.  Changing  various 
aspects  of  the  maintenance  comeptfs)  may  have  varying  effects  on  LCC.  Use  sensitivity  analysis  to 
determine  the  effect  on  LCC  by  changing  the  maintenance  concept. 

g.  Models  and  Data;  Use  only  accepted,  proven  models  and  data.  Use  the 
simplest  models  to  do  the  job.  If  an  accepted,  approved  nxxiel  does  not  exist,  obtaining  SAF/FM 
(CAIG)  and  OSD/PA&E  acceptance  of  the  proposed  methodology  in  the  COEA I  study  plan  is  critical. 

c.  The  analysis  examines  a  broad  range  of  alternative  concepts  to  satisfy  the  mission  need. 
During  this  phase,  there  will  be  considerable  uncertainty  in  both  the  p^ormance  and  cost  estimates.  In 
many  cases,  performance  and  cost  are  only  predictable  in  terms  of  bands.  Document  the  uncertainties 
and  the  source  of  all  information.  The  CO^  will  help  define  the  performance,  operational,  and  support 
characteristics  and  capabilities  most  affecting  mission  accomplishment  to  establish  the  program  design 
and  cost  objectives  for  Phase  I.  The  analysis  may  include  force-on-force  analysis  to  evaluate  alternative 
operational  concepts.  Express  performance  expectations  and  costs  as  intervals,  (i.e.,  between  a  low  and 
high  value),  using  parametric  estimating  techniques.  Cost  estimates  should  take  into  account  acjvanc^ 
research  and  development  and  engineering  development  as  well  as  procurement  and  operation  and 
support  costs  although,  during  phase  I,  the  cost  estimates  will  be  very  uncertain.  Qualify  these  early  cost 
estimates  to  highlight  their  uncertainties  and  any  pcjssibility  for  gross  errors  and  identify,  to  the  extent 
known,  the  characteristics  of  each  conc^t  that  drive  the  cost  estimates  and  uncertainties.  Sensitivity 
analysis  should  be  performed  on  system  characteristics  to  better  understand  the  military  utility  of  each 
concept.  The  COEA  I  will  also  provide  an  analysis  plan  of  cost  and  operational  trade-offs  to  be 
examined  as  part  of  the  Milestone  l/IV  decision. 
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d.  The  COEA I  Report  provided  to  the  operating  command  should  address  specific  items. 

These  are  basically  the  same  as  listed  above,  from  the  COEA  I  study  plan.  Besides  those  listed  above, 
the  report  to  the  operating  command,  beyond  those  mentioned  above,  must  address: 

1.  Performing  the  Analysis 

a.  Effectiveness  Analysis:  The  aim  of  performance  or  effectiveness  analysis  is 
to  measure  the  ability  of  the  alternatives  to  accomplish  the  functional  objectives  and  herrce  meet  the 
mission  needs.  As  previously  discussed,  MOEs  are  used  to  measure  this  ability.  Identify  the  probability 
that  the  proposed  system  will  operate  when  required.  This  probability  results  from  concept  survivability, 
vulnerability  to  countermeasures,  maintainability,  and  reliability,  as  well  as  other  factors. 

b.  Cost  Analysis:  The  purpose  of  the  cost  analysis  is  to  determine  the  cost 
ranking  of  alternatives.  The  analysis  should  not  include  any  sunk  costs,  but  these  costs  should  be 
identified  and  noted  separately.  At  this  phase,  all  alternatives  should  be  costed  in  constant  year  dollars 
of  the  selected  base  year.  If  production  schedules  are  known,  the  alternatives  should  also  be  done  in 
then  year  dollars.  Current  policy  requires  that  Net  Present  Value  (NPV)  and  constant  year  (base  year) 
dollars  be  provided. 


c.  Cost/Effectiveness  Analysis: 

-  Maintain  a  balance  between  cost  and  effectiveness. 

-  Compare  equal  cost  or  equal  effectiveness  alternatives,  i.e.,  for  a 
certain  LCC  what  effectiveness  does  each  alternative  provide  and  for  a  certain  effectiveness  what  is  the 
LCC  for  each  alternative. 

•  Avoid  ratios 

d.  TradeK>ff  Analysis:  The  purpose  of  the  trade-off  analysis  is  to  identify  the 
strengths  and  weaknesses  of  the  alternatives  and  to  identify  the  preferred  solution.  The  MOPs  and  the 
cost  for  each  alternative  are  used  to  investigate  the  utility  of  changes  in  each  measure.  This  process  is 
one  of  comparing  alternatives  as  described  in  Cost/Effectiveness  Analysis  but  also  of  doing  sensitivity 
analysis  on  critical  MOPs.  The  final  task  is  to  prioritize  the  alternatives.  Key  items  should  be  assessed, 
such  as  cost,  effectiveness,  risk,  military  utilKy,  supportability,  and  countermeasures.  For  Milestone  I, 
the  analysis  will  focus  on  the  operational  utility  (effectiveness)  of  the  proposed  system.  Since  the  system 
is  not  fully  defined  at  this  point,  both  performance  and  cost  estimates  are  very  rough.  Consequently, 
aHematives  should  not  be  discarded  at  this  juncture  without  good  ^stification. 

d.  Linkage  between  the  MNS,  COEA,  ORD,  and  Test  and  Evaluation  Master  Plan  (TEMP)  is 
vital.  The  MNS  and  ORD  were  d  :ajssed.  The  TEMP  should  document  how  the  COEA  MOEs  and 
related  MOPs  will  be  addressed  ii •  ihe  TEMP.  Maintain  consistency  between  all  the  acquisition 
management  documentation.  In  particular,  the  MOEs,  MOPs.  and  criteria  in  the  ORD,  the  COEA,  the 
TEMP  and  the  APB,  should  be  consistent.  If  the  comparative  analysis  does  not  do  this,  the  project  team 
is  not  serving  the  customer  well.  If  test  limitations  exist,  the  analysis  should  explain  in  a  quantitative 
evaluation  how  and  to  what  extent  COEA  results  would  be  expected  to  vary  as  a  result  of  test  limitations. 

e.  The  comparative  analysis  is  basically  the  essence  of  the  COEA  I  report,  so  present  the 
analysis  information  in  such  a  way  that  the  operating  command  can  use  the  comparative  analysis  in  the 
report.  The  COEA  report  summarizes  the  essential  elemer^s  of  the  analysis  and  presents  the  results  in 
terms  of  relative  cost  and  utility.  To  the  extent  possible,  identify  the  cost  drivers  and  high  risk  areas  for 
each  option.  The  system  alternatives  in  the  COEA  and  those  in  the  independent  cost  analysis,  if 
required,  will  be  the  same. 
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8.  ENTRANCeEXIT  CRITERIA: 

a.  Entrance  Criteria;  This  activity  literaHy  starts  Pre-Milestone  0  while  the  AFMC  center  is 
assisting  the  operating  command  with  their  mission  needs  analysis  since  the  data,  intomnation.  and 
knowledge  gerterated  are  carried  forward  and  updated  during  the  Phase  0  studies  and  analysis.  A  center 
will  officially  start  doing  comparative  analysis  for  the  COEA  orKe  the  Operating  Command  'contracts* 
with  a  center  for  the  COEA  analysis.  Should  a  center  be  the  supplier  of  choice,  the  ceraer  should  be  a 
member  of  the  Operating  Command  CAG.  C16. 

b.  Exit  Criteria:  This  activity  is  an  iterative  process  between  the  Operating  Command  and  the 
Center.  Various  trade  studies  and  questions  will  be  asked  throughout  the  Phase  0  analysis  activities. 
Further  comparisons  could  be  required  throughout  Phase  0  and  even  Phase  I.  Consequently,  one 
cannot  assume  completion  until  a  Milestone  l/IV  decision  is  made  (A22). 

9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs: 


(1)  The  COEA  I  Plan  including  assumptions,  methodology,  etc.  (Cl  7). 

(2)  The  most  current  project  data  collected  to  date  (D44). 

(3)  Complete  and  current  information  on  the  development  of  the  ORD  I  (C19). 

(4)  Operating  commands  selectbn  of  COEA  I  concepts  (C21 ). 

(5)  Complete  and  current  information  on  the  analysis  of  program  alternatives  (D46). 


b.  Outputs; 


(1)  Provide  all  the  information  required  for  user  to  select  the  preferred  altemative(s) 
(C25),  conduct  a  program  alternatives  review,  and  complete  a  COEA  I  Report  (C23). 

(2)  Considerable  data  is  collected  during  this  activity  and  must  be  retained  in  the  project 

database  (049). 

10.  KEY  REFERENCES: 

a.  DoDI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,23  Feb  91 ,  Part  4. 
(See  REQUIREMENT) 

b.  DoDM  5000.2-M,  Defense  Acquisition  Management  Documentation  and  Reports,  Feb  91 .  Part 
8.  Provides  information  on  how  to  conduct  a  COEA  and  also  provides  the  format  for  the  COEA  report. 

c.  AFPD  10-6,  Mission  Needs  and  Operational  Requirements,  19  Jan  93.  Shows  the 
relationship  between  the  COEA  and  ORO  and  AC  AT  and  COEA  approval  levels. 

d.  AFM  0-601 ,  Mission  Needs  and  Operational  Requirement  Guidance  and  Procedures,  1 6  Feb 
93.  Shows  relationship  between  Milestone  0  decision  and  COEA  and  the  COEA  procedures  and  format. 

e.  AFMCP  173-1 ,  AFMC  Cost  S  Operational  Effectiveness  Analysis  (COEA)  Guide,  30  Dec  92. 
Provides  guidance  and  procedures  for  developing  and  processing  Air  Force  COEAs,  when  COEAs  are 
required,  how  they  are  used,  key  elements,  organizational  structure,  and  agency  responsibilities. 

1 1 .  IMPLEMENT ATION  TOOLS:  See  the  list  of  mod^s  in  AFMCP  1 73-1 ,  Appendices  3  and  4. 
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12.  PLANNING  GUIDANCE: 

a.  DURATION:  Goal  is  180  days  troin  PMD  issuance  unlit  draft  COEA I  report  is  distribuled  by 
the  Curating  Command.  This  time  frarne  depends  on  pending  Milestone  I  review,  summits,  etc.  If 
conditions  and  time  permit,  a  longer  suspense  wM  be  allowed  (AF1 10^1,  Attachment  9).  Based  upon 
experience,  180  days  is  unrealistic.  Planning,  coonftnation,  aryj  approval  of  a  COEA  plan  lor  a  m^r 
program  can  easily  consume  180  days  with  much  more  time  requir^  to  execifte  the  COEA  and  thm 
write,  coordinate,  and  brief  the  results.  Contracted  COEAs  have  taken  up  to  2  years.  The  typical  COEA 
is  takes  1  year. 

b.  CONSTRAINTS: 


See  DURATION.  A  COEA  report  is  distributed  and  all  recipients  (AP1 10-601 , 
Attachment  10)  have  45  days  for  review.  AC  AT  I  COEA  reports  must  be  approved  by  the  AF  Acquisition 
Executive  at  least  60  days  prior  to  the  Milestone  1  review  or  sunwnit.  Operating  Comnutnd  Commanders 
a^rove  less  than  ACAT I  COEA  reports,  and  they  must  also  be  approved  at  least  60  days  prior  to  the 
Milestone  1  review  or  summit.  One  possible  conflict  in  the  approval  process  is  that  AP1 10-601  states 
that,  ^nerally,  a  summit  should  be  scheduled  at  least  180  days  bekxe  the  next  scheduled  Joint 
Requirements  Oversight  Council  or  OAB  review.  The  tack  of  formal  procedures  for  accomplishing  joint 
COEAs  is  a  constraint.  As  the  OoD  moves  toward  more  joint  programs,  the  services  must  develop  these 
procedures.  HQ  USAF/XOME  is  currently  working  (mid  93)  procedures.  The  Joint  Direct  Attack  Missile, 
Joint  Stand-off  Weapon,  arxl  Joint  Primary  Aircraft  Training  System  (JPATS)  programs  are  a  forcing 
function  for  this  activity.  However,  there  will  be  significant  challenges  to  developing  these  ptx>cedures: 

-  Both  the  Army  and  Navy  truly  have  irKlependent  COEAs  in  that  the  user  is  rKil 
responsible  for  conducting  the  COEA  as  in  the  AP. 

•  The  AP  uses  a  CAG,  consisting  of  action  officers,  for  COEA  oversight.  The 
Navy  has  an  oversight  board  of  higher  ranking  officers.  R>r  ACAT  I  programs,  the  Navy's  over^ltt 
board  consists  of  flag  officers.  A  typical  board  would  consist  of; 

•  Assistant  Secretary  of  the  Navy  (RD&A)  staff 

•  Deputy  Chief  of  Naval  Operations  (N8)  (flag  representative) 

•  Program  sponsor 

•  Director  of  Test  and  Evaluation 

-  Director  of  Naval  Irftelligence 

-  Supporting  systems  command  representative 

-  Program  manager  representative 

Oversight  boards  for  lower  level  ACAT  programs  consist  of  0-6s  and  O-Ss.  At  one  point,  when  the  Navy 
was  going  to  be  the  lead  service  for  JPATS,  the  AF  was  going  to  have  HQ  USAP/XO  (a  three  star)  sit  on 
the  oversight  board. 

c.  RESOURCES:  Contracted  COEAs  have  cost  up  to  several  million  dollars  while  the  typical 
COEA  costs  about  $1  mHlion. 

d.  LESSONS  LEARNED: 


systems. 


-  A  frequerft  weakness  is  inadequate  atterftion  to  potential  modifications  of  existing 


-  If  contractor  support  is  needed,  identify  funds  early  -  preferably  Pre-Milestone  0.  Also, 
identify  a  contracting  vehicle. 

-  At  this  time,  there  are  no  formal  procedures  for  conducting  and  coordinating  a  joint 

COEA. 


D-444 


Mown 


-  Mittary  personnel  at  the  op«ating  commands  are  reassigned  roughly  every  3  years,  so 
be  sure  to  continually  communicate  wvith  the  user.  The  protect  team  is  their  ’corporate  memory.’ 

-  Bringing  an  operating  commarxt  represeritative  ’up  to  speed*  may  be  a  significant 

workload. 

-  Ensure  COEA  is  consistent  with  the  project  office  estimate  and  component  cost 
estimate  (previously  known  as  the  independent  cost  analysis). 

e.  BEST  PRACTICES: 

-  Keep  the  document  as  brief  and  concise  as  possible  to  depict  relevant  information 
without  adding  levete  of  detail  exceeding  those  required.  Put  details  in  an  apperKlix  or  reference  a  file 
location. 

-  Allow  for  new  or  modified  altematives  to  be  added  as  the  analysis  proceeds  and  new 
options  are  identified  or  old  options  refined.  Remember,  this  is  an  iterative  process. 

-  Get  the  intelligence  community  involved  early. 

•  Coordinate  the  models  used  with  the  AF  CAIG  and  OSD(PA&E)  eariy  in  the  process. 

-  Define  the  methodology  and  analysis  steps  in  enough  detail  so  that  any  other 
organization  can  replicate  the  analysis. 

•  Under  current  HQ  AFMC  guidance,  the  operating  command  may  select  a  center  as 
their  COEA  supplier  of  choice. 

f.  TRAPS: 

•  Attempting  to  examine  too  broad  of  a  range  of  altematives.  The  range  must  be 
manageable  and  must  cover  the  minimum  range  of  altematives  directed  by  the  ADM  and  PMD. 

•  Do  rK)t  include  altematives  that  are  obviously  unsuitable;  however,  orte  or  two 
sentences  will  be  required  in  the  analysis  report  explaining  why  an  alternative  was  judged  unsuitable.  If 
there  is  a  question  as  to  the  suitability  of  an  alternative,  include  it.  On  the  other  hand,  if  rough  order  of 
magnitude  estimates  of  cost  or  performance  indicate  an  akemative  is  clearly  unsurtable,  the  estinrates 
need  not  be  refined. 

•  Making  assumptions  that  are  not  consistent  with  the  MNS,  ADM.  PMD,  and  other 
project  documentation  being  developed. 


-  Using  ratios  in  the  effectivity  analyses. 

-  HQ  USAF/XOR  currently  does  not  accept  as  policy  the  guidance  provided  in  the  Under 
Secretary  of  Defense  for  Acquisition  Memorandum,  Implementation  Guidelines  for  Relating  CQEA 
MQEs  to  Test  and  Evaluation,  9  Mar  92. 
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1.  ELEMENT;  D49.  TBS  1. 2.3.5  ( IFC  93-3) 

2.  ELEMENT  TITLE:  Update  Database 

3.  ELEMENT  OWNERS:  Oper^ing  Command.  Implememing  Command.  Product  Center  Development 
Planning  Dvedorate  (XR)  arxt  Progrwn  DevelopmerS  SPO  (ASC/YX).  Industry 

4.  ELEMENT  STAKEHOLDERS: 

a.  Implementing  Agencies:  Department  of  Defense  (DOD).  Secretary  of  the  Air  Force  (SAF). 
Implementing  Command.  Product  Center  XR  and  YX  (ASC). 

b.  Supporting  Agencies;  Air  Force  Intelligence  Support  Agency  (AFISA).  Air  Force  Studies  and 
Analysis  Agency  (AFSAA).  Laboratories.  Industry.  Operating  Commands. 

5.  REQUIREMENT: 

a.  Air  Force  Policy  Directive  (AFPD)  10-6.  Mission  Needs  and  Operational  Requirements.  19 
January  1993:  This  directive  requires  the  implementation  of  the  DOD  5000  series  documents,  which  in 
turn  requires  the  maintenance  of  database. 

b.  AFPD  37-1 .  Information  Management;  (On  order,  upon  receiving  document,  the  definition 
will  be  constructed). 

c.  AFPD  63-1.  Acquisition  System:  (On  order). 

d.  AFR  55-43.  Management  Operations.  Test  and  Evaluation.  29  Jun  90:  This  regulation 
describes  the  support  document  requirements  and  the  Data  Management  arxf  Analysis  Plan. 

e.  Department  Of  Defense  Directive  (DODD)  5000.1.  Defense  Acquisition.  23  Feb  91 : 
Establishes  a  disciplined  management  approach  for  acquiring  systems  and  materiel  that  satisfy  the 
operational  user's  needs. 

f.  DODD  8320.1 .  Data  Administration.  26  Sep  90;  (On  onler) 

g.  MtL-STD-1388-1 A.  Logistics  Support  Analysis  (LSA).  1 1  Apr  83;  The  goal  of  this  standard  is 
a  single,  uniform  approach  by  the  Military  Services  for  conducting  activities  necessary  to  cause 
supportability  requirements  to  be  an  integral  part  of  system  requirements  and  design,  with  documentation 
developed  and  maintained. 

h.  M(L-STD-499B.  Systems  Engineering.  Draft;  The  decision  database  may  be  digital,  defined 
by  the  Government  or  left  open  for  contractor  definition. 

i.  MIL-STD-1388-2B,  DOD  Requirements  for  a  Logistics  Support  Analysis  Record,  28  Mar  91 : 
This  standard  is  directed  toward  in^roving  the  cost  effectiveness  of  the  generation,  maintenance, 
acquisition,  and  use  of  the  technical  data  required  to  support  an  LSA  program. 

j.  MIL-STD-1840A,  Automated  Interchange  of  Technical  Information,  22  Dec  87:  The  purpose 
of  this  standard  is  to  standardize  the  digital  interface  between  organizations  or  systems  exchanging 
digital  forms  of  technical  information  necessary  for  the  logistic  support  of  weapon  systems  throughout 
their  life  cycle. 
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6.  PURPOSeOBJECTIVES: 

a.  Purpose:  The  purpose  of  the  program  database  is  to  provide  a  central  location  for  the 
collection  and  storage  of  information  /  data.  This  inform^ion  /  data  wilt  support  the  Project  Team  in 
making  decisions  that  respond  to  external  and  internal  requirements,  (i.e.  the  information  neerte  of 
milestone  decision  authority). 

b.  Objective:  At  this  point  the  database  is  updated  using  Phase  0  project  activities  planned  since 
the  update  of  Project  Database.  D44. 


«) 


7.  DESCRIPTION: 

a.  The  database  is  the  updated  information  used  and  ger^erated  for  integrated  requirements  and 
flowdowns;  interface  constraints  and  configuration  alternatives:  verifications;  decision  criteria;  trade  study 
assessments;  and  any  other  required  documents.  It  includes  physical  and  mathematical  models, 
computer  simulations,  layouts,  and  similar  configuration  documentation  and  technical  data,  as 
appropriate.  The  performing  activity  selects  the  specific  data  entry  media,  storage,  and  maintenance 
proce^res.  At  this  stage  the  database  captures  the  examination  of  the  preferred  alterruitives.  including 
COEA  Comparative  analysis  (D48),  Program  Alternative  Analysis  (D46).  and  other  data  from  the 
Alternative  Systems  Review  (D45). 

b.  The  preliminary  user  of  this  stage  of  data  depository  is  the  preferred  alternatives  definition 
process.  It  i  uses  the  program  cost  estimating  processes.  It  ultimately  feeds  into  the  Integrated  Program 
Strategy  process  Plan  and  Organize  for  Program,  Big  Block  1 .3).  At  this  point  the  database  will  contain 
sufficient  approved  data  to  generate  the  Request  for  Proposal  D64)  and  to  develop  Draft  Cost  Analysis 
Requirement  Description  (D52).  The  update  Program  Cc^  Estimate  (D47)  is  using  already  existing 
specifications  together  with  parametrics.  quantities  and  schedules  from  the  database,  for  the  Preferred 
Concept  Alternative.  D37B). 

8  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  This  is  a  continuous  activity,  intended  to  be  current  since  established  in  D15,  and 
updated  in  D-31 ,  and  D-44. 

b.  Exit;  The  Data  Base  will  continually  be  updated  throughout  the  pre-milestone  1  process  and 

beyond. 

9.  KEY  INPUTS  AND  OUTPUT: 

a.  Input: 

From  COEA  Comparative  Analysis  (D48): 

(1)  COEA  I  Report 

(2)  Life  Cycle  Cost  Estimate 

(3)  Altemative  Systems  Performance/Supportability  Analysis 

(4)  Theater/Campaign  Analysis 

(5)  One-on-One  Operational  Analysis 

(6)  Mission  Analysis 

(7)  Comparison  of  Alternatives  From  Program  Alternatives  Analysis  (D46) 

(a)  Program  Altemative  Analysis  Report 

(b)  Program  Risks  for  Alternatives 

(c)  User  inputs  to  program  development  impacts 

(d)  Other  approved  pertinent  data  since  D44 
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b.  Output: 

(1 )  All  above  inpiAs  serve  as  unaltered  outputs  as  needed. 

(2)  Data  to  Updated  Program  Cr^  Estimate<D47). 

Life  Cycle  Costs  and  other  cost  estimatirig  factors  and  relationships 

Program  Schedules. 

Quantities 

(3)  Combination  of  data  to  conduct  Concept  Definition  for  Preferred  AKematives 

(D37B). 

10.  KEY  REFERENCES:  (In  addition  to  those  listed  in  Requirements.  Paragraph  5) 

a.  Air  Force  Instruction  (API)  10-601 .  Mission  Needs  and  Operational  Requirements  Guidance 
and  Procedures,  16  Feb  93:  Identifies  official  Air  Force  information  required  for  decision  making  and 
historical  purpose  and  develop  a  schedule  of  the  information  life  cycle  to  describe  creation, 
maintenance,  and  disposition  (API  37-123,  Management  of  Records). 

b.  AP1 10-602,  Logistics  Support  and  Readiness  Requirements:  (On  order,  upon  receiving 
documerrt,  the  definition  wilt  be  written.) 

c.  AP1 14-303,  Threat  Support,  Acquisition  Process:  (On  order). 

d.  AP1 16-501,  Control  and  Documentation,  Air  Force  Programs:  (On  order). 

e.  API  33-105,  Information  System,  Standard  Programs:  (On  order). 

f.  API  37-1 ,  Information  Management:  (On  order). 

g.  API  37-123,  Management  of  Records:  Identifies  the  activities  to  plan,  design,  model, 
synchronize,  standardize  and  control  Air  Force  Corporate  data  at  all  echelons 

h.  API  37-150.  Data  Administration  and  Standards  Program:  (On  order). 

i.  DOD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 :  Establishes  an  integrated  framework  for  translating  broadly  stated  mission  needs  into  stable, 
affordable  acquisition  programs  that  meet  the  operational  user's  needs  and  can  be  sustained,  given 
projected  resource  constraints. 

j.  DOD  Manual  5000.2M,  Defense  Acquisition  Management  Documentation  and  Reports,  23  Feb 
91 :  This  Manual  implements  relevant  portions  of  DODD  5000.1  and  DODD  5000.2.  Specific 
responsfoilities  pertaining  to  major  areas  are  provided  in  each  individual  section,  as  appropriate. 

k.  Implementing  Command:  Submit  required  acquisition  program  documents.  (Defense 
Planning  Guide,  Mission  Area  Assessment,  and  Mission  Needs  Analysis,  etc.). 

l.  MIL-HDBK-59A,  DOD  Computer-Aided  Acquisition  and  Logistic  Support  (CALS)  Program 
Implementation  Guide:  The  purpose  of  this  military  han<fi}ook  is  to  provide  general  information  and 
detailed  application  guidance  for  contractually  implementing  CALS  requirements  in  weapon  system  and 
related  major  equipment  procurements. 
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m.  MIL-HDBK-X499-3.  Systems  Engineering/Configuration  Management.  Draft:  The  decision 
database  will  provide  an  audit  trail  from  initially  stated  needs  and  requirements  to  the  current  description 
of  system  products  and  processes. 

n.  Secretary  of  the  Air  Force  (SAF/AAI);  SAF/AAI  will  ensure  comp'iarx:e  with  DOD  Corporate 
Information  Management  (CIM)  to  allow  sharing  of  data  with  appropriate  DOD  ageix:ies  and  other 
Government  agerKies. 

o.  Supporting  Command;  The  Supporting  Command  will  collect  and  process  Integrated  Logistic 
Support  (ILS)  information  in  the  Logistics  Management  Information  System  (LMIS).  CXjtline  the  actions, 
support,  and  documerrtation  needed  to  establish  maintenance  requirements  for  on  and  off  equipment 
throughout  the  life  of  the  system,  identify  data  collection  and  analysis  efforts  that  will  continue  after 
fielding  of  system  equipment. 

p.  Using  /Operating  Command:  The  user  will  ensure  data  and  management  needs  are 
identified.  Integrate  the  Logistics  Support  Analysis  process  with  the  System  Requirements  /^ysis 
activity.  Outline  the  actions,  support,  and  documentation  needed  to  establish  maintenance  requirements 
for  on  and  off  equipment  throughout  the  life  of  the  system. 

11.  IMPLEMENTATION  TOOLS: 

a.  Automated  Data  Processmg  (ADP)  is  available  as  Government  Furnished  Property  (GFP). 

Contact; 


D 
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Director  USAMC  Logistic  Support  /^ivity 
ATTN.:  AMXLC-AL 
Lexington.  KY  40511-5101 
606-293-4193  (Mr.  David  Henderson) 

b.  Computer-Aided  Acquisition  and  Logistic  Support  (CALS):  The  repository  of  information  used 
and  generated  at  the  appropriate  level  for  the  acquisition  phase  of  integrated  requirements  arx) 
flowdowns;  interface  constraints  and  requirements;  functional  and  performance  requirements;  system 
concept;  preliminary  design  and  configuration  alternatives;  details  design;  verifications;  decision  criteria; 
trade  study  assessments;  system,  subsystem,  and  functional  capability  assessments;  and  other  required 
documentation. 


(a)  MIL-HOBK-59A 

(b)  MIL-STD-1840A 

c.  Systems  and  Logistics  Integration  Capability  (^IC).  This  is  a  state-of-the-art.  DOD  Type  III 
validated,  microcomputer  based  LSAR  system  that  can  be  used  to  completely  satisfy  all  MIL-STD-1 388- 
2A  requirements  with  total  independence  from  any  other  hardware  and  software. 

(a)  SLIC  I 

(b)  SLIC  II 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Update  the  database  continuously,  throughout  the  life  of  the  product. 
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b.  CONSTRAINTS: 

(1 )  Identify  computer  resource  constraints  (examples  include  language,  computer,  data 
base,  architecture,  or  interoperability  constraints). 

(2)  Database  capacity  (identify  spare  memory  and  throughput  requirements,  computer 
memory  growth  3CKJirements,  software  partitioning  and  modular  design  requirements  such  as  software 
module  size  (e.g.,  no  greater  than  100  lines  of  code). 

(3)  Access  capabilities 

(4)  Security  restrictions 

(5)  Time 

(6)  Assumptions 

(7)  Funds 

(8)  Management  Resources 

(9)  Training 

C.  RESOURCES: 

(1)  Facilities 

(a)  Classified  work  space 

(b)  Personnel  office  space  and  supplies 

(c)  Database  location 

(2)  Computer  hardware  and  software  programs 

(a)  Analytical  models 

(b)  Program  Management  Software 

(3)  Security 

(a)  Type  of  access  required 

(b)  Provide  access  for  contractors 

(4)  Manpower 

(a)  Security  personnel 

(b)  Computer  systems  personnel 

(c)  Data  management  personnel 

d.  LESSONS  LEARNED:  (Rrst  two  lessons  transcribed  from  ALLC7  "IS,  the  others  are 
referenced). 


f! 
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(1)  #  1982,  Program  Directors:  Enhanced  quality  and  quantity  of  information  on  the 
AFAM  database.  Improvements  include  additional  lessons  learnt  and  best  practices,  updated 
references,  increased  number  of  tools  such  as  software  programs,  document  templates,  samples,  and 
courses.  (Col.  Ferrell,  ASC/CYM,  DSN  785-2213) 

(2)  #1344,  Schedule  Plan  For  A  Source  Selection:  Develop  a  detailed  plan  for  the 
execution  of  source  selection  that  will  aid  the  flow  of  data  and  provide  exp^ient  changes  to 
contingencies.  All  data  were  computerized  on  an  IBM  program  called  "Super  Project."  The  data  was 
placed  in  a  network  to  define  the  internal  relationships  of  activities  and  resources  and  a  Gantt  chart  was 
used  to  provide  scherkile  suspense  dates  and  serve  as  a  tracking  tool.  By  computerizing  the  data  base 
"what-iT  scenario's  could  be  evaluated  based  on  unknown  contingencies  (i.e.,  slip  of  data  reviews, 
modifications  to  the  proposals,  personnel  conflicts  or  absences.)  The  database  was  used  as  a  "living 
tooP  to  help  manage  200  evaluators,  18  evaluation  items,  and  7  proposals.  (PCX^  will  be  added  at  later 
date.) 

(3)  #  1264,  AFLC  LMS  Target  Operating  Environment 

(4)  #1418,  Internal  Financial  Managemern. 
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(5)  #1888,  Program  Managers: 

(6)  #  1982,  Program  Directors 

(7)  #  9020.  Hardness  Surveillance  Test  Systems  (PHSTS) 

(8)  #  9063,  Air  Force  Electronic  Combat  Office  (AFECO  )  • 

(9)  #9115,  ASIAC 

(10)  #9116,  Reliability  Analysis  Center  (RAC) 

e.  BEST  PRACTICES: 

Use  MIL-HDBK-59A,  DOD  CALS  Program  Implementation  Guide,  and  MIL-STD-1840A,  • 

Automated  Interchange  of  Technical  Information  to  control  data  storage  with  frequent  backups  to  avoid 
the  loss  of  data. 

f.  TRAPS: 

Ncncon'ipatible  CALS  systems  have  problems  with  non-standard  terminology  used  to  • 

file  or  retrieve  data. 


» 
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1.  ELEMENT:  DSO,  TBS  1.3.1 .1  (IFC93-3) 

2.  ELEMENT  TITLE:  Develop  Preliminary  Systems  Threat  Assessment  (Report)  (STA(R)) 

3.  ELEMENT  OWNER(S):  OIA/DT-AS.  AFISA/INK  Project  Office 

4.  ELEMENT  STAKEHOLOER(S):  Product  Center  Director  of  Intelligence  (Dl)  (For  ASC  it  is 
ASC/FASTC/TAIA).  AFISA/INAA.  DIA/DT-AS,  AFISA/INK  Project  oHice,  AFMC/IN 

5.  REQUIREMENT 

a.  DoD  5000.2-M,  Feb  91 ,  Part  5.  Policies  and  procedures  for  developing  a  STA(R). 

b.  DoDI  5000.2, 23  Feb  91 .  Part  4,  Section  A,  pg.  4-A-1 .  Defines  intelligence  support  required 
for  acquisition  programs. 

c.  Air  Force  Policy  Directive  10-6.  Defines  requirement  for  STA(R). 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  Mission  needs  and  the  defense  acquisition  programs  that  may  result  shall  be  based 
on  current,  authoritative  threat  information.  A  System  Threat  Analysis  Report  (STAR)  will  be  prepared 
and  be  current  and  validated  prior  to  each  milestone  decision  review  beginning  with  MS  I. 

STARS  are  required  for  ACAT  1C  and  ID  programs,  and  for  major  modifications,  as  defined  by 
AF  Policy  Directive  1 0-6.  It  will  be  the  primary  threat  reference  for  the  Operational  Requirements 
Document  (ORD),  the  Cost  and  Operational  Effectiveness  Assessment  (COEA),  the  Integrated  Program 
Summary  (IPS),  and  the  Test  and  Evaluation  Master  Plan  (TEMP). 

If  the  program  is  not  ACAT  I,  (i.e.  ACAT  ll-IV),  the  threat  report  is  called  a  System  Threat 
Assessment  (STA)  and  is  accomplish^  by  the  Component  Command  Intelligence  Agency  -  AF/IN  for  Air 
Force  projects/programs.  The  procedures  for  a  STA  are  essentially  the  same  as  for  a  STAR. 

b.  Objective:  The  objective  of  this  block  is  to  get  a  threat  document  produced  that  will 
compliment  the  acquisition  process.  Provide  decision  makers  an  analysis  of  the  threat  environment  that 
the  system  will  encounter. 

7.  DESCRIPTION: 

a.  The  STA(R)  is  required  prior  to  going  to  a  review  for  the  program.  It  must  be  initiated  with 
sufficient  time  to  write  a  complete  and  factual  document.  The  STA(R)  should  be  written  for  the  preferred 
concept.  Thus,  it  fits  into  the  flow  of  the  process  prior  to  the  roundtable  discussion  and  about  the  same 
time  as  the  preferred  concept  is  being  determined.  The  STAR  is  the  basic  authoritative  threat 
assessment  tailored  for,  and  focused  on  a  particular  US  defense  acquisition  program.  The  Director  of 
Intelligence  (Dl)  is  responsible  for  writi^  and  up^ting  the  STAR.  Included  in  the  STAR  is  an 
assessment  of  those  projected  capabilities,  doctrine,  strategy,  tactics,  organization,  equipment,  and 
military  forces  that  a  potential  enemy  could  use  to  defeat  or  degrade  the  US  system  during  its 
employment.  The  STAR  focuses  on  two  specific  points  in  time,  initial  operational  capability  (ICX^)  of  the 
US  system  and  IOC  plus  ten  years  (lAW  DoDM  5000.2M,  Part  5,  pg.  5-1-2). 

b.  A  STAR  contains; 

1 .  a  preface 

2.  an  executive  summary  with  a  threat  matrix 
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3.  a  description  of  the  system  and  operational  cortcept  (including  a  reference  to  the 
Program  Protection  Plan) 

4.  the  operational  threat  environment 

5.  targets 

6.  system  specific  threats 

7.  the  reactive/lechnologically  feasible  threat 

8.  appendices: 

a.  the  critical  intelligence  parameters  (CIPs) 

b.  CIP  threat  status  and  associated  intelligerK»  production  requirements  (IPRs) 

c.  list  of  references 

d.  distribution  list. 

c.  When  the  Dl,  in  coordination  with  the  System  Program  Director  (SPD),  the  Air  Force 
Intelligence  Support  Agency  (AFISA),  the  Defense  Intelligence  Agency  (DIA),  HQ  AFMC,  and  the  using 
command  determine  the  STAR  is  recpjired  or  needs  to  be  updated,  the  Dl  organization  will  begin  the 
process. 

d.  The  initial  STA(R)  is  initiated  as  follows;  A  Threat  Steering  Group  (TSG)  chaired  by  HQ 
AFISA,  is  convened  to  assist  in  drafting  the  document.  The  Acquisition  Command  (AFMC)  initiates, 
prepares,  and  coordinates  the  draft  STA(R)  document,  obtains  HQ  USAF/IN  approval  and  produces  the 
STAR  in  accordance  with  a  schedule  determined  by  the  TSG,  (usually  within  180  days  of  the  Program 
Management  Directive).  DIA  then  validates  the  STAR  for  ACAT I  programs  and  AFISA  validates  the 
STA  for  other  programs. 

e.  The  group  reviews  the  system  description  and  the  concept  of  operations  for  significant 
changes  since  the  last  STAR  was  published.  Based  on  the  US  system  description,  changes  in  the  threat 
are  discussed.  The  group  produces  a  threat  matrix  containing  a  general  description  of  the  threat  (i.e., 
surface-to-air  missiles)  and  an  estimate  of  the  likelihood  of  occurrence.  Threat  Environment  Descriptions 
(TED)  are  used  as  the  baseline  documentation  for  development  of  the  STAR. 

f.  The  threat  matrix  is  the  outline  for  the  STAR  and  is  contained  in  the  executive  summary  of  the 
STAR  to  provide  a  quick  overview  of  the  threat  to  senior  decision-makers.  Once  the  first  draft  of  the 
STAR  is  produced,  it  is  distributed  to  all  members  of  the  TSG  for  review. 

g.  The  ASC  Director  of  IntelligerKe,  ASC/FASTC/TAIA.  (DSN  785-4285)  writes  the  STAR  at 
ASC.  In  this  case  the  STAR  is  developed  to  support  a  MS  I  review.  The  STAR  is  developed  to  support 
the  preferred  concept(s)  selected  by  the  MAJCOM  following  the  development  of  the  Cost  and 
Operational  Effectiveness  Assessment  (COEA)  for  Phase  0.  Only  one  STAR  is  developed  for  each 
pr^ential  program  and  it  should  be  based  on  the  preferred  concept(s)  to  be  presented  at  the  milestone 
review. 

8.  ENTRANCE/EXIT  CRITERIA: 


a.  Entrance;  Several  documents  are  required  before  work  on  the  STAR  begins.  A  Mission  Need 
Statement  is  required  C13  and  A6)  from  the  Operating  Command  or  JROC  (Joint  Requirements 
Oversight  Council).  A  Concept  of  Operations  (see  Cl 9 )  is  required  from  the  Operating  Command.  And 
finally,  a  Systems  Requirements  Description  is  required  from  the  SPO  (D37B).  Any  other  systems 
documents  that  would  give  a  better  understanding  of  the  system,  its  technologies,  and  its  operations, 
would  be  helpful  to  the  Intelligence  Analysts  and  allow  them  to  write  a  better  STAR. 

b.  Exit;  A  STA(R)  in  the  proper  format  is  the  exit  from  this  block.  It  is  required  to  be  validated 
and  given  to  the  acquisition  decision  makers  for  their  review. 
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9.  KEY  INPUTS  AND  OUTPUTS: 


a.  Inputs:  The  niajor  input  is  from  block  D37B  Conduct  Concept  Definition  for  Preferred 
Alternatives.  This  gives  the  intelligence  community  the  proper  focus.  The  STAR  should  be  written  for 
the  preferred  concept(s)  to  eliminate  any  unnecessary  documentation. 

b.  CXitputs:  CXitput  is  to  blocks  051  -  Develop  Preliminary  Acquisition  Program  Baseline;  D54  - 
Develop  Preliminary  Test  and  Evaluation  Master  Plan  (TEMP);  and  D57  -  Conduct  Strategic  Roundtable. 

10.  KEY  REFERENCES:  AFSCR  200-3,  Threat  Assessment  Documentation,  Atch  1 , 5  Apr  85. 
Describes  how  to  write  a  threat  document. 

11.  IMPLEMENTATION  TOOLS:  The  STAR  will  use  the  TEOs  developed  to  support  the  overall  MNS  to 
derive  their  baseline  data.  All  other  relative  intelligence  sources  will  be  used. 

12.  PLANNING  GUIDANCE: 

Points  Of  Contact: 

Organization  Commercial  DSN 

HQ  AFMC/IN  513-257-2869  787-2869 

DIA/OTD-AS  203-373-4740  243-4740 

AFISA/INAA  703-695-7578  225-7578 

ESC/IN  617-377-2377  478-2377 

ASC/FASTC/TAIA  513-255-4285  785-4285 

a.  DURATION:  A  STA(R)  takes  time  to  develop.  Normal  estimates  of  development  time  are 
from  one  to  six  months  or  more.  A  potential  major  program  focusing  10-15  years  in  the  future  may  take 
6  months  or  rrxve  while  a  smaller  eftort  may  take  a  few  months. 

b.  CONSTRAINTS:  Data  may  be  limited  based  on  the  intelligence  database  pertaining  to  the 
specific  threat  and  system  under  consideration. 

c.  RESOURCES:  Normally  one  person  is  put  in  charge  of  developing  the  STA(R)  and  will 
require  numerous  (2  to  1 0)  additional  personnel  to  assist  in  the  data  collection  and  report  writing.  At 
least  one  person  from  the  project  office  should  be  put  in  charge  of  monitoring  the  development  of  the 
STAR. 

d.  LESSONS  LEARNED:  What  can  the  program  office  do  with  the  STAR?  The  STAR  is  to  be 
submitted  to  the  reviewing  authority  to  determine  the  relationship  between  the  mission  need  and  the 
threat.  The  program  should  model  aixf  analyze  its  requirements  against  the  threat.  Inputs  from  the 
STAR  can  be  used  in  the  Requirements  Correlation  Matrix  and  the  Test  and  Evaluation  Master  Plan. 

The  STAR  can  also  be  used  to  justify  program  changes,  slips,  etc. 

e.  BEST  PRACTICES: 

1 .  Early  in  the  program  K  is  advisable  to  establish  a  working  group  to  develop  the 
information  required.  There  is  no  formal  requirement  to  have  a  Threat  Working  Group  (TWG),  or  any 
other  group,  to  write  a  System  Threat  Assessment.  Common  sense  and  best  practices  dictate  the  need 
for  a  group  that  will  dedicate  effort  to  the  production  of  a  STAR.  A  TWG,  a  Threat  Steering  Group 
(TSG),  or  some  otiier  working  group  is  in  order. 


2.  If  a  TWG  is  desired  a  few  thoughts  for  that  activity  follow.  The  TWG  acts  as  a  forum 
for  threat  assessment  and  evakjation  of  threat  environments  and  threat  related  subiects.  The  TWG 
drafts  the  threat  documentation  required  for  the  appropriate  phase  of  the  program. 

3.  The  Acquisition  Command  can  form  and  chair  a  TWG  for  each  HQ  USAF-directed 
acquisition  program.  For  smaller  programs,  only  one  TWG  may  be  needed;  for  large  scale  programs 
(i.e.,  new  aircraft),  many  TWGs  may  be  operating  cortcurrently.  The  TWG  is  comprised  of  the  ¥Mxking 
level  representatives  of  all  agencies  (NAIC,  DIA,  CIA.  AFIA,  contractors,  etc.)  participating  in  the  specific 
threat  assessment.  TWG  members  are  responsible  for  constructing  detailed  threat  support 
documentation,  preparing  support  material  for  technical  arKf  project  reviews,  and  reducing  and  analyzing 
intelligence  data.  TWGs  convene  when  required.  The  Project  Manager  (PM)  must  ensure  appropriate 
planning  and  programming  has  been  done  to  enable  all  required  agencies  to  participate  in  specific 
TWGs  for  the  duration  of  the  specific  project  effort. 

4.  The  TWG  must  be  formed  in  time  to  altow  for  early  arKf  thorough  threat  planning  and 
coordinating  with  proper  agencies.  It  functions  as  long  as  threat  documentation  is  being  prepared  for  the 
proje^  office,  and  should  be  reconvened  when  necessary  to  update  the  threat  documentation  as  required 
for  milestone  reviews  or  when  there  is  a  significant  breach  in  the  project  baseline  or  change  in  the  threat 
environment. 


5.  The  TWG  team  should  include  representatives  from  all  intelligence  agencies  external 
to  the  project  office  that  may  be  involved  during  the  life  of  the  project.  Based  on  the  threat  environment 
and  documentation  requirement,  the  project  manager  may  establish  and  formalize  (perhaps  through 
Memoranda  of  Agreement  or  contract)  relationships  with  all  agencies  required  to  participate  in  threat 
documentation  over  the  expected  life  cycle  of  the  system.  Ideally,  a  single  focal  point  from  each 
participating  agency  will  be  identified  for  inclusion  on  the  threat  working  group.  Memoranda  of 
Agreemerrt  and  contracts  will  specify  exactly  what  is  expected  from  each  agency  in  planning  r  and 
conducting  threat  assessment  work.  The  project  manager  may  need  to  consider  budgeting  for  support 
for  some  agencies  which,  while  crucial  to  the  program,  have  severely  limited  budgets.  When  these 
agencies  and  representatives  have  been  identified  they  should  all  become  part  of  the  TWG. 

6.  The  TWG  must  accomplish  the  fdtowing  to  get  the  project  going  on  the  right  foot: 

a.  Analyze  threat  information  /  intelligence  data. 

b.  Validate  threat  environment. 

c.  Develop  threat  assessment. 

d.  Develop  the  threat  documentation. 

7.  The  process  of  threat  analysis  arKf  documentation  is  lengthy.  It  should  be  started  as 
soon  as  possible  after  the  basic  program  is  defined  or  at  least  as  soon  as  a  framework  for  the  program  is 
developed.  Time  frame  for  completion  is  on  the  order  of  months. 

8.  Prior  to  establishing  the  TWG,  the  project  office  must  be  organized  and  manned. 

The  TWG  should  be  formed  at  the  same  time  the  Mission  Area  Assessment  and  Mission  Needs 
Assessment  is  being  done.  This  will  help  in  the  development  of  the  Mission  Needs  Statement. 

9.  Thefor,  programming  fo  TWG  can  be  an  overwhelming  activity.  There  are  usually 
numerous  people  interested  in  the  activities  of  the  TWG.  If  you  are  not  careful,  the  TWG  will  get  too  big 
and  not  function  as  a  planning  group  but  as  a  review  group.  Make  efforts  to  control  the  number  of 
people  on  the  group. 

10.  The  time  required  for  a  TWG  varies  with  the  complexity  of  the  project.  It  could  be 
as  little  as  a  day  to  as  much  as  several  months.  The  TWG  typically  meets  once  a  quarter,  or  as  required 
as  you  approach  a  milestone  review.  The  TWG  will  require  a  meeting  facility  appropriate  to  the  security 
level  of  the  project.  Further,  the  size  of  the  TWG  will  dictate  the  facility  requirements  for  the  meeting. 
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f.  TRAPS:  It  is  the  project  office's  responsi>iMy  to  ensure  the  STAf  R)  is  initiated.  Just  because 
a  PMD  is  issued  foflowing  a  MS  0  review,  do  not  assume  that  the  intelligence  community  knows  about  it 
and  initiates  the  report.  The  intelligence  community  wi8  try  k)  anticipate  your  needs  but  do  not  count  on 
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1.  ELEMENT:  D51,  TBS  1.3.1. 2  (IFC93-3) 

2.  ELEMENT  TITLE:  Develop  Preiiminaiy  APB 

3.  ELEMENT  OWNER(S):  SAF/AQXA 

4.  ELEMENT  STAKEHOLOER(S):  Project  Teams.  ASC  SPOs,  PEO.  DAC.  Operating  Command 

5.  REQUIREMENT :  DoOl  5000.2,  23  Feb  91 .  Part  1 1 .  Section  A,  Program  Objectives  and  Baselirtes. 
Establishes  the  policy  and  procedures  lor  the  preparation,  submittal,  approval,  and  reporting  of  APBs. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  the  Acquisition  Program  Baseline  (APB)  is  to  enhance  project 
stability,  provide  a  criticai  reference  poirit  for  measuring  and  reporting  the  status  of  project 
implefnentation,  and  provide  early  warning  and  management  visibility. 

b.  Objectives:  The  APB  defines  the  prefect  in  terms  of  key  parameters  which  ideally  represent 
the  most  cost  effective  and  timely  approach  for  fielding  a  new  system  that  satisfies  the  mission  need. 
The  APB  formally  documents  the  pre^  into  an  agreement  among  all  interested  participants,  including 
user,  project  manager,  logistician,  tester,  trainer,  and  service  headquarters. 

7.  DESCRIPTION: 

a.  The  APB  describes  the  cost,  schedule,  and  performance  objectives  for  the  project  and  is 
prepared  by  the  Project  Team.  It  is  essential  to  have  G^)erating  (^mmand  participation  in  each 
acquisition  phase  to  ensure  consistent  performance  ob^ctives  in  the  Operational  Requirements 
Document  (ORD)  and  the  APB,  and  to  keep  the  objectives  operationally  meanirtgful.  These  objectives 
include  a  set  of  minimum  acceptable  requirements,  which  are  identified  in  the  ORD  (Cl  9),  and  are 
incorporated  in  the  APB,  the  Test  and  Evaluation  Master  Plan  (TEMP)  (D54),  and  the  Cost  and 
Operational  Effectiveness  Analysis  (COEA)  (D37B)  as  thresholds.  The  APB  for  Phase  I,  Demonstration 
and  Validation,  establishes  the  Concept  Baseline  and  is  approved  by  the  Milestone  Decision  Authority 
(MDA).  See  DoD  5000.2-M,  Part  14,  for  detailed  instructions  on  preparation  of  APBs. 

b.  The  Concept  Baseline  (APB  for  MS  I)  corttains  broad  objectives  and  thresholds  for  key  cost, 
schedule,  and  performance  parameters.  Supportability  is  included  in  the  performance  parameters.  Key 
parameters  are  those  that,  if  the  thresholds  are  not  met,  the  MDA  would  require  a  re-evaluation  of 
alternative  concepts  or  design  approaches.  The  thresholds  establish  deviation  limits,  i.e.  the  parameters 
beyond  which  the  Project  Team  may  not  trade  off  cost,  schedule,  or  performance  without  authorization 
from  the  MDA. 


(1 )  The  thresholds  for  the  key  performance  parameters  identified  in  the  Concept 
Baseline  will  be  the  mininrHim  acceptable  operational  requirements  identified  in  the  ORD  for  those 
parameters. 


(a)  If  a  required  operational  capability  date  is  identified  in  the  ORD,  it  will  be 

included  in  the  Concept  Baseline  as  a  schedule  threshold.  • 

(b)  Cost  thresholds  will  be  established  by  the  MDA  based  on  affordability 

assessments. 


(2)  Project  objectives  evolve  from  broad,  general  objectives  at  Milestone  I  to  system- 
specific,  detailed  requirements  at  Milestone  III.  Objectives  should  be  established  based  on  the  results  of 
concept  definition  studies,  erst  and  operational  effectiveness  analyses,  and  affordability  assessments 
(D37B). 
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(a)  Objectives  should  be  reasonable  and  re^ic  and.  in  ttte  case  ol 
performance  parameters,  should  reflect  an  operationally  mestfmgM.  measurable,  cost  effective,  and 
affordable  increment  in  capabiHy  beyond  the  thresholds. 

(b)  Performartce  objectives  in  the  Concept  Baseline  should  be  the  startfog  point 
for  developing  initial  draft  system  specifications  during  Phase  I,  Oemonstraion,  and  Validation. 

(c)  Project  objectives  are  established  based  on  the  results  of  the  preceding 

phase(s). 

(3)  The  APB  wM  be  submitted  by  the  des^nated  component  official  through  the  MDA 
chain  as  a  stand-alone  part  of  the  Milestone  I  documentation  package.  The  APB  will  be  approved  or 
modified  by  the  MDA  as  a  result  of  a  favorable  MUestorte  I  decision. 

(a)  For  Acquisition  Category  (ACAT)  1C  projects,  the  Air  Force  Acquisition 
Executive  (AFAE)  will  approve  the  baseline  and  fonward  an  information  copy  of  the  baseline  to  the  Under 
Secretary  of  Defense  for  Acquisition  (Attn:  Defense  Acquisition  Board  (DAB)  Executive  Secretary)  within 
10  days  of  approval. 


(b)  For  ACAT  ID  projects,  the  AFAE  win  submit  the  baseline  to  the  Under 
Secretary  of  Defense  for  Acquisition  for  approval. 

(c)  For  ACAT  I  projects  coming  before  the  DAB,  performance  objectives  and 
thresholds  must  be  submitted  to  the  Joint  Requirements  Oversight  Council  (JROC)  for  review  and 
confirmation  that  the  resulting  capabilities  satisfy  the  mission  need  prior  to  each  Milestone  review. 

(d)  For  ACAT  II  through  IV  projects,  the  baselme  will  be  approved  by  the  MDA. 

c.  APBs  and  deviation  r^rting  are  required  for  all  acquisition  categories.  The  formality  of  the 
baseline  and  the  deviation  reporting  vanes  by  acquisition  category. 

(1 )  ACAT  I  projects  have  formal  baselines  and  deviation  reporting  in  accordance  with 
the  formats  and  reporting  procedures  specified  in  DoD  5000.2-M. 

(2)  APB  format,  deviation  criteria,  and  deviation  reporting  for  ACAT  II,  III,  and  IV 
projects  is  specific^  by  the  MDA.  The  APBs  are  tailored  to  the  priority,  value,  and  risk  inherent  in  the 
project.  ACAT  It  through  IV  projects  will  generally  have  tailored  APBs  with  lesser  detail  than  ACAT  I 
prefects. 


(3)  The  P^ect  Team  maintains  a  current  estimate  of  the  project  actually  being 
executed.  The  current  estimate  shows  the  trade-off  between  cost,  schedule,  and  performance  nufoe  by 
the  Project  Team  as  well  as  changes  made  in  the  project  external  to  the  Project  Team  (e.g.,  by 
Congressional  action). 

(4)  Project  breaches  occur  when  the  current  estimate  of  the  project  falls  outside  one  or 
more  APB  thresholds. 

(5)  The  method  of  advising  the  MDA  ol  project  breaches  is  through  project  deviation 
reporting.  See  DoD  5000.2-M,  Part  19,  for  instructions  on  preparation  of  project  deviation  reports.  At 
A^,  the  Corporate  Management  Network  (CMN)  triggers  breach  notices  for  different  levels  of 
management. 

d.  The  vehicles  for  reporting  on  current  approved  APBs  are  the  Selected  Acquisition  Report 
(reference  DoD  5000.2-M,  Part  17)  and  the  Defense  Acquisition  Executive  Summary  refx>rt  (reference 
DoD  5000.2-M,  Part  16). 
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9.  Once  Signed  by  the  MOA.  Ares  wiH  only  be  changed  at  subsequent  miieslone  or  proieci 
reviews  or,  with  me  approval  oi  me  MDA.  as  a  response  to  an  unrecoverable  baseline  devi^ion  (breach). 

f.  The  DoO  Ojmponents  may  supplement  the  APB  with  an  assessment  stmcture  explicitly 
tailored  to  measure  the  Prc^  Team's  performance  relative  to  the  directed  project. 

(1 )  The  content,  format,  and  reporting  frer^iency  of  this  assessment  structure  will  be 
determined  by  the  Component. 

(2)  This  assessment  structure  will  not  be  the  basis  for  Defense  Acquisition  Executive 
Summary,  Selected  Acquisition  Report,  or  project  deviation  reporting. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  APB  will  be  submitted  by  me  Project  Team  through  me  decision  chain  to  the 
MDA  as  a  stand-alone  part  of  the  milestone  documentation  package. 

b.  Exit;  The  APB  will  be  approved  with  me  Acquisition  Decision  Memorandum  (ADM)  following 
a  milestone  or  project  review  by  the  MDA. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  Draft  ORD  (Cld) 

Affordability  Assessments  (D37B) 

COEA  Cornparative  Analysis  (D37B) 

Concept  Definition  Studies  (D37B) 

•  b.  Outputs:  Final  APB 

10.  KEY  REFERENCES: 

a.  DoDI  5000.2, 23  Feb  91 ,  Part  4,  Section  B,  Evolutionary  Requirements  Definition, 

Paragraphs  2.b  and  2.c  and  subs,  Pages  4-B-1  and  4-B-2.  Descril^  system  performance  objectives 
and  minimum  acceptable  requirements  for  operational  performance  to  be  included  in  the  ORD  and  APB. 

b.  DoDI  5000.2-M,  Feb  91 ,  Part  14,  Acquisition  Program  Baselines,  contains  instructions  for 
preparation  of  Acquisition  Program  Baselines. 

c.  DoDI  5000.2-M,  Feb  91,  Part  19,  Program  Deviation  Report,  contains  instructions  for 
preparation  of  Program  Deviation  Reports. 

d.  Air  Force  Acquisition  Model  (AFAM). 

e.  SAF/AQ  Policy  Letter  92M-012.  26  May  92.  Acquisitbn  Program  Baseline  (APB)  Policy 
MenfX)  91 M-006  -  INFORMATION  MEMORANDUM.  Directs  that  future  APBs  will  be  accomplished  in 
accordance  with  DoDI  5000.2  and  DoD  5000 .2M  and  that  expanded  guidance  will  be  provid^  in  AF 
supplements  to  5000.2  and  2M. 

11.  IMPLEMENTATION  TOOLS:  Ckrrporate  Management  Network  (CMN).  AFAM. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  This  task  has  historically  taken  anywhere  from  several  weeks  to  a  couple  of 
years.  The  difference  in  the  time  is  due  to  me  complexity  of  the  project,  whether  it  is  the  initial  APB  or 
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just  an  update  of  an  already  a^tprwed  APB,  and  the  number  of  internal  and  external  organizations 
required  for  coordination.  Th^  is  a  push  now  to  turn  the  APBs  around  in  a  more  timely  fashion; 
however,  it  has  yet  to  be  accomplished. 

b.  CONSTRAINTS: 

(1 )  Restrictions  regarding  the  time  in  which  the  document  must  be  completed. 

(2)  Restrictions  on  the  availability  of  needed  project  staff. 

(3)  Identification  of  other  organizations/irxfivtduals  with  which  you  must  interface. 

(4)  Restrictions  regarding  the  proper  format  in  which  the  document  must  be  produced. 

c.  RESOURCES:  This  task  requires  at  least  one  individual  on  the  project  team  to  gather  inputs, 
compile  the  inputs  into  an  APB  format,  and  get  the  required  coordination  from  all  participating  offices.  It 
also  requires  use  of  a  computer  with  a  good  word  processing  program  and  a  reliable  printer. 

d.  LESSONS  LEARNED: 

(1 )  Requirements  must  be  clearly  defined/baselined  and  agreements  reached  within  the 
operating  command  prior  to  release  of  a  Request  for  Proposal  (RFP).  In  addition,  a  project  cost  baseline 
must  be  established  against  which  progress  can  be  measured.  Most  project  slips,  cost  increases,  and 
technical  problems  result  from  poo^  defined  requirements.  (Reference  AF  Lessons  Learned  #1273). 

(2)  Do  not  prepare  the  APB  and  file  it  away  with  the  other  project  documents;  it  needs  to 
be  incorporated  into  contractor  performance  measurement  criteria.  Failure  to  systematically  track 
performarK:e  against  the  APB  will  result  in  a  huge  workload  to  assess  the  reasons  for  the  prMential/actual 
breach.  This  will  not  allow  management  actions  to  be  taken  to  identify  and  solve  problems  early. 

e.  BEST  PRACTICES: 

(1 )  The  baseline  document  is  a  summary  of  key  parameters  only  and  does  not  provide 
detailed  project  requirements  or  content.  The  intent  of  the  baseline  is  to  capture  the  key  parameters  that 
define  the  system.  Thus,  the  number  of  key  parameters  should  be  small  (maybe  5-10  performance 
items).  The  objective  is  to  enhance  project  stability  and  control  cost  growth. 

(2)  Budget  must  match  risk  level  and  must  cover  ALL  cost  elements,  not  just  the 
contractor  effort. 

(3)  A  good  APB  becomes  the  management  tool  for  the  project.  It  is  not  a  report;  it  is  the 
’bible''  of  the  project. 

(4)  A  draft  APB  should  be  provided  to  the  operating  command,  the  Program  Element 
Monitor  (PEM),  and  any  other  office  required  for  coordination  of  the  APB  for  review  arxJ  comment  before 
going  final.  This  would  ensure  all  participants  are  in  agreement  with  the  information  contained  in  the 
APB.  Should  consider  irtcluding  industry  review  of  the  draft  APB. 

(5)  The  APB  should  definitely  be  included  in  the  Request  for  Proposal  (RFP)  library. 

f.  TRAPS:  See  Lessons  Learned. 


•  • 
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1.  ELEMENT:  D52.  TBS  1.2.4.5.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Develop  DraH  Cost  Analysis  Requirements  Descri(4ion  (CARD) 

3.  ELEMENT  OWNER(S):  OSD/PA&E 

4.  ELEMENT  STAKEHOLOER(S):  OSD  CAIG.  AF  CAIQ,  AFCAA.  Product  Center  Staff,  Project  Office. 
Anyone  involved  in  preparing  or  reviewing  a  cost  estimate. 

5.  REQUIREMENT:  DODI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures.  Change 
1 , 26  Feb  93.  Part  1 1 ,  Section  C,  Attachment  1  indicates  CARD  is  required  no  later  than  Milestorte 
Planning  Meeting. 

DOD  5000.4-M,  AcquisKion  Policy  93M-012, 28  Jun  93,  Provides  information  on  developing  the  CARD. 

6.  PURPOSeOBJECnVES: 

a.  Purpose;  Develop  a  technical  and  programmatic  description  of  selected  altemative(s)  that 
can  be  used  by  the  cost  analysts  to  support  estimating  the  cost  of  the  altemative(s). 

b.  Objectives: 

(1 )  Provide  the  program  office  cost  estimating  and  the  component  cost  analysis  teams 
with  a  common  basis  for  their  project  cost  estimates. 

(2)  Describe  the  salient  features  of  the  program  and  of  the  system  to  be  estimated. 

(3)  Facilitate  the  identification  of  any  area  or  issue  that  could  have  a  significant  effect  on 

life-cycle  costs. 

7.  DESCRIPTION: 

a.  Once  the  preferred  altemative(s)  has  been  identified  (C25),  the  Integrated  Product  Team 
(IPT)  needs  to  start  preparing/updating  the  documentation  required  for  a  Milestone  I  review  (B24  &  A22). 
The  Life  Cycle  Cost  Estimate(s)  (D71 ,  B21 ,  &  A1 7)  will  be  one  of  the  primary  documents  used  by  the 
Milestone  Decision  Authority.  DOD  5000.2-M,  Part  15,  rer^ires  establishment  of  a  baseline  description 
of  these  cost  estimates.  This  basis  is  to  provide  a  descrption  of  the  salient  features  of  the  acquisition 
program  and  of  the  system  itself.  This  description  is  defined  as  the  CARD.  The  CARD  should  be 
comprehensive  enough  to  facilitate  identification  of  any  area  or  issue  that  could  have  a  significant  effect 
on  the  life  cycle  cost  and  therefore  must  be  addressed  by  the  cost  analyst.  DOD  5000.4-M  provides 
guidelines  for  the  preparation  and  maintenance  of  a  CARD.  The  CARD  is  used  by  the  team  preparing 
the  project  office  estimate  (D53  &  D71 )  and  the  agency(s)  preparing  the  independent  cost 
estimate(s)/component  cost  analysis  (C23).  Therefore,  the  CARD  should  be  flexible  eixxjgh  to 
accommodate  the  use  of  various  estimating  methodologies. 

b.  Several  cost  estimates  were  probably  prepared  during  the  Cost  and  Operational 
Effectiveness  Analysis  (COEA)  studies  (D48)  and  used  by  the  Operating  Command  to  select  the 
preferred  alternative  (C25).  The  basis  for  each  of  these  estimates  should  have  been  documented,  but 
may  not  be  in  the  desired  format,  or  as  comprehensive  as  necessary  for  a  program  Milestone  I  review. 
This  information  should  provide  a  good  place  to  start  when  developing  the  CARD. 

c.  At  this  stage  of  the  project,  typically  only  limited  technical,  support,  and  programmatic 
information  is  available.  Accordingly,  the  CARD  for  a  project  in  Phase  0  may  present  the  information  in 
terms  of  ranges  of  potential  outcomes.  This  information  should  be  consistent  with  CAG  direction,  the 
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Program  Data  Base  (Block  D49)  information,  and  the  assumptions  and  data  utilized  in  the  COEA.  Other 
information  will  become  available  as  the  preferred  altemative/concept  is  further  defined  (D37B)  and  as 
the  acquisition  strategy  is  developed  (D58).  If  a  source  document  is  referenced  in  the  CARD,  it  should 
be  included  as  an  attachment  to  the  CARD. 

d.  The  necessary  program  information  would  include  the  system  description,  development  and 
production  schedules,  quantities,  and  acquisition  and  support  strategies.  Ail  programmatic  assumptions 
should  be  documented  in  the  CARD.  Although  a  CARD  is  ortly  required  documentation  for  ACAT  I  &  II 
program  reviews,  developing  a  CARD  at  this  time  should  provide  valuable  insight  into  areas  that  warrant 
further  analysis  for  any  program.  Moreover,  even  when  not  mandatory,  the  development  of  a  CARD 
should  improve  both  the  quality  and  credibility  of  the  cost  estimate. 

e.  A  project  manager  should  head  up  the  effort  to  write  the  CARD.  The  source  for  program 
description  information  should  be  functional  experts  (engineering,  manufacturirrg,  contracts,  logistics,  test 
and  management)  and  Operating  Command  personnel.  It  is  imperative  that  senior  functional  personnel, 
knowledgeable  in  both  program  acquisition  and  the  specific  program,  be  involved  in  this  program 
planning.  The  results  of  this  program  definition  effort  should  be  well  documented  and  any  revisions 
tracked.  (Note:  This  cannot  be  overemphasized,  since  all  levels  of  Air  Force  management  will  require 
tracking  b^ween  program  cost  estimates  provided  to  them.) 

f.  A  CARD  should  be  regarded  as  a  “living"  document  that  is  updated  as  technical  or 
programmatic  changes  occur  in  preparation  for  DAB  reviews  and  POE  updates.  The  updates  should 
document  and  track  changes  that  have  occurred  and  should  incorporate  additional  data  developed  since 
the  last  update. 

g.  A  CARD  is  prepared  by  the  system  program  office  (SPO)  (or  an  organization  specified  by  the 
sponsoring  DoD  Component  if  a  program  office  does  not  exist)  for  each  preferred  alternative  resulting 
from  the  cost  and  operational  effectiveness  analysis  (COEA).  When  appropriate,  CARDs  can  be 
prepared  as  excursions  to  the  preferred  altemative(s)  or  one  of  the  other  alternatives.  CARDs  are 
approved  by  the  Program  Executive  Officer  (PEO)  or  the  Designated  Acquisition  Commander  (DAC). 

8.  ENTF,ANCeEXIT  CRITERIA: 

a.  Entrance: 

(1) .  Draft  Cost  arxi  Operational  Effectiveness  Analysis  (COEA)  report  prioritizes 
alternatives  (D48). 

(2) .  Preferred  altemative(s)  selected  (C25). 

(3) .  Conceptual  System  Definition  (D37b)  has  progressed  sufficiently  to  support 
preparing  draft  CARD. 

b.  Exit:  CARD  has  been  drafted  and  addresses  all  elements  required  by  DOD  5000.4-M. 

9.  KEY  INPUTS  AND  OUTPUTS:  PLEASE  NOTE:  This  early  in  program,  key  information  may  not 
exist  and  the  source  documents  may  or  may  not  have  been  started.  Also,  several  activities  are  taking 
place  which  will  further  define  the  technical  and  programmatic  aspects  of  the  project.  As  these  activites 
proceed,  the  CARD  should  be  updated  to  reflect  the  latest  information. 

a.  INPUTS: 

-  Milestone  0  Program  Management  Directive  (B10)  -  Identifies  which  alternatives  are 

to  be  studied. 
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-  COEA  Report  (D48). 

-  000  5000.4  M,  Chapter  l  provides  an  *Outiir)e  of  CARO  Basic  Structure'  which 
defines  what  information  each  paragraph  should  contain.  The  following  list  iderttifies  some  of  the 
information  the  CARO  should  contain.  It  also  irKjicates  some  of  the  documents  that  may  contain  the 
required  information. 

(1)  System  configuration  (037B) 

(2)  Mission  Need  Statement  (A8) 

(3)  System  Threat  Analysis  Report  (050) 

(4)  Relationship  to  other  systems  (037B) 

(5)  Major  factors  influencing  cost  (037B) 

(6)  Technical  description  of  the  hardware  and  software  (037B) 

(7)  Human  characteristics  of  the  system  (037B) 

(8)  Preliminary  Integrated  Manpower,  Personn^  and  Comprehensive  Training  arxj 
Safety  (IMPACTS)  Program  Plan  (P-IPP)  (C11) 

(9)  Project  Manager's  Risk  Assessment/Abatement  Plan  (055) 

(10)  Unit  Manpower  Oocument  (022) 

(11)  Integrated  Logistics  Support  Plan  (023) 

(12)  Total  System  Training  Plan  (60) 

(13)  Quantity  Requirements(037B) 

(14)  System  Manpower  Requirements  (Cl  1 ) 

(15)  System  Activity  Rates  (037B) 

(16)  System  Milestone  Schedule  (055) 

(17)  Acquisition  Plan  and/or  Strategy  (058) 

(18)  System  Oevelopment  Plan  (037B) 

(19)  TEMP  (054) 

(20)  Facilities  requ  /ments  (037B) 

(21)  Environnriental  Impact  Analysis  (057) 

As  you  can  see  many  inputs  are  required  to  develop  the  CARD. 

b.  OUTPUTS:  The  draft  CARD.  The  following  top  level  outline  identifies  the  major  sections  in  a 
CARD.  OoO  5000.4-M,  Chapter  1 ,  provides  a  detailed  description  of  what  is  required  in  each  section. 

I . 0  System  Overview 
2.0  Risk 

3.0  System  Operational  Concept 
4.0  Quantity  Requirements 
5.0  System  Manpower  Requirements 
6.0  System  Activity  Rates 
7.0  System  Milestone  Schedule 
8.0  Acquisition  Plan  and/or  Strategy 
9.0  System  Oevelopment  Plan 
10.0  Element  Facilities  Rec^jirements 

I I . 0  T rack  to  Prior  CARD 

12.0  Contractor  Cost  Data  Reporting  Plan 

10.  KEY  REFERENCES: 


a.  DoDD  5000.2-M,  Defense  Acquisition  Management  Documentation  and  Reports,  Feb  91 . 
Part  15  requires  development  of  the  CARD. 
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b.  DODI  5000.4,  OSD  Cost  Analysis  Improvement  Group  (CAIG),  24  Nov  92.  Section  D 
outlines  the  OSD  CAIG's  role  in  using  and  reviewing  the  CARD. 

c.  DOD  5000  4-M,  Cost  Analysis  Guidance  and  Procedures,  Dec  92.  Chapter  1  provides  * 

guidelines  for  the  preparation  and  maintenance  of  a  CARD. 

11.  IMPLEMENTATION  TOOLS:  None  Identified 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  length  of  time  to  develop  a  CARD  depends  on  how  much  of  the 
information  is  readily  available  or  has  to  be  created.  If  a  good  job  was  done  during  the  COEA,  it  may 
only  take  a  few  weeks  to  pull  together  a  CARD.  If  you  are  siariing  from  scratch,  it  could  take  months  to 
develop  all  the  information  needed. 

b.  CONSTRAINTS:  Limited  technical/programmatic  detail  prior  to  MS  I,  when  developing  initial  * 

CARD.  Much  technical  detail  is  unavailable  until  after  MS  II. 

c.  RESOURCES: 

(1)  As  a  minimum,  initial  development  will  probably  require  approximately  40  hours 

from  each  of  the  functional  areas  as  previously  identified.  Resources  required  for  updates  will  vary  * 

depending  on  how  much  has  changed  or  been  learned  since  the  last  update. 

(2)  The  ASC  cost  staff  has  identified  a  focal  point  for  CARDs. 

d.  LESSONS  LEARNED:  A  project  manager  should  lead  the  effort  to  develop  the  CARD; 

however,  it  is  essential  that  the  cost  analyst(s)  responsible  for  preparing  the  POE  and  the  CCA  * 

participate  in  the  review  process.  These  analysts  should  perform  a  quality  check  to  ensure  that  the 
CARD  is  as  complete  as  possible  and  contains  all  the  information  they  will  need  to  prepare  their 
estimates. 

e.  BEST  PRACTICES:  OSD  is  currently  asking  for  a  CARD  for  each  alternative  considered  by 

the  COEA.  Air  Force  plans  to  require  a  CARD  only  for  the  preferred  alternative(s).  If  nrore  than  one  * 

CARD  is  required,  it  is  advisable  to  prepare  the  CARD  for  the  primary  alternative  and  prepare  excursions 
to  it  for  the  other  alternatives  to  minimize  the  amount  of  time  and  resources  required. 

f.  TRAPS:  None  Identified. 
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2.  ELEMENT  TITLE:  Update  Program  Cost  Estimate. 

3.  ELEMENT  OWNER:  ASC/FM. 
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4.  ELEMENT  STAKEHOLOER(S):  Hq  USAF.  Operating  Command,  Program  Element  Monitor 
(PEM).  Project  Team,  ASC/AL. 

5.  REQUIREMENT:  ASDR  173-1, 17  Jan  89.  Aeronautical  Systems  Division  Cost  Analysis  * 

Program,  defines  the  cost  estimating  responsibilities  and  requirements  for  project/program  offices 

at  ASC,  and  provides  comprehensive  guidartce  on  estimating  documentation.  The  requirements 
remain  the  same,  regardless  of  ACAT  level. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  purpose  of  this  activity  is  to  generate  and  document  an  estimate  of  the 
financial  requirements  for  the  anticipated  program. 

b.  Objective:  The  objective  of  documenting  a  program  estimate  at  this  time  is  twofold. 

First,  since  the  estimate  should  be  based  on  the  recommended  program  alternative  from  the 

preferred  altemative(s)  selection  (C25),  the  estimate  documentation  can  be  used  to  support  any  ^ 

program  or  cost  analysis  reviews  by  the  Operating  Command  or  Airstaff.  For  ACAT  I  programs,  or 

any  programs  that  will  be  submitted  for  an  Air  Force  Requirements  Summit,  the  estimate  will  be 

necessary  to  support  this  review.  Further,  the  documentation  should  be  the  basis  for  the  formal 

program  estimate  that  must  be  submitted  for  the  Milestone  I  decision  review.  Second,  the 

estimate  can  be  used  to  support  the  budget  process  •  if  there  is  an  opportunity  to  submit  a 

budgetary  input  into  the  Air  Force  Program  Objective  Memorandum  (POM)  or  a  Budget  Estimate  • 

Submission  (BES)  for  the  anticipated  program,  the  estimate  documentation  would  sen/e  as  the 
basis  for  the  submission. 

7.  DESCRIPTION:  The  estimate  scope  should  include  all  program  life  cycle  costs:  development, 
production,  operating  and  support,  and  disposal.  The  development  of  the  cost  estimate  can  be 

grouped  into  five  major  activities  which  are  summarized  below.  The  reader  will  firxl  a  more  • 

detailed  description  of  these  tasks  in  Chapter  3  of  Vol.  1  of  the  referenced  AFSC  Cost  Estimating 
Handbook.  In  addition,  more  detail  is  provided  in  other  chapters  of  the  handbook  as  noted  below; 

a.  Defining  the  estimate  -  this  effort  consists  of  defining  the  program  to  be  estimated, 
determining  the  scope  of  the  estimate,  assembling  the  estimating  team  and  assigning 

responsibilities,  and  defining  estimate  groundrules,  assumptions,  and  constraints.  The  estimating  * 

team  should  consist  of  the  cost  analysts  and  all  functional  support  personnel  identified  to  support 

the  estimating  effort.  This  should  be  documented  in  the  estimate  plan,  and  approved  by  the 

Project  Manager.  The  estimate  plan  should  contain  a  schedule  for  the  estimating  activities  based 

on  the  estimated  time  required  to  accomplish  the  following  estimating  tasks.  The  time  required  for 

each  of  the  activities  can  be  expected  to  vary  for  every  estimate,  depending  on  the  size  and 

experience  level  of  the  team,  prior  research  and  estimating  efforts  for  the  program,  etc.  Specific  * 

sources  of  information  which  should  help  define  the  program  to  be  estimated  are  contained  in  Key 
Inputs  (Section  9.a.),  which  follows  (Chapter  4). 

b.  Research  -  the  cost  analysts  p^>rform  initial  research  to  determine  appropriate 
estimating  methodologies,  and  perform  data  collection  to  determine  if  information  can  be  obtained 

to  support  the  selected  estimating  approach(es)  (Chapter  5).  • 
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c.  Develop  the  estimating  approach  -  the  preliminary  estimating  methods  are  selected, 
and  any  estimating  tools  are  designed  or  updated,  as  appropriate  (Chapter  6). 

d.  Perform  estimate  and  crosschecks  -  the  analysts  generate  the  detailed  estimates  and 
verify  the  results  with  any  appropriate  crosschecks  to  ensure  the  results  are  logical,  reasonable, 
and  complete.  (Note:  An  estimate  documented  to  support  either  a  Milestone  review  or  a  budget 
submission  must  reflect  a  "point  estimate*.  However,  if  possible,  the  estimators  should  provide 
estimate  ranges  to  the  decision  makers  to  aid  in  the  estimate  review  and  approval  process) 

(Chapter  4,  Paragraph  4.5.3.). 

e.  Documentation  and  approval  -  the  estimate  must  be  documented  and  provided  to 
project  management  for  approval.  This  process  usually  involves  presentation  of  the  estimate  to 
the  senior  program  and  functional  managers  assigned  to  the  project.  After  internal  approval,  if  the 
estimate  is  to  be  utilized  for  project  decision  making  purposes,  it  should  be  provided  to  the 
Operating  Command  for  review  and  approval.  After  this  is  completed,  the  estimate  should  be 
considered  the  formal  Program  Estimate,  and  should  be  the  basis  for  all  program  estimate  ‘what 
ifs"  and  budget  submissions  until  superseded  by  another  formal  program  estimate.  The  reader 
should  refer  to  Chapter  22,  of  the  referenced  AFMC  Cost  Estimatirtg  Handbook,  or  ASDR  173-1  for 
more  detailed  information  on  ASC  estimate  documentation  requirements. 

8.  ENTRANCBEXIT  CRITERIA: 

a.  Entrance; 

(1)  This  estimating  activity  should  be  initiated  when  the  COEA  analysis  has  been 
performed  and  the  preferred  program  option  has  been  determined  (C25).  The  estimate  should 
support  project  planning  activities,  and  it  should  be  generated  in  time  to  support  any  requirements 
identified  by  the  Operating  Command,  assumed  here  to  be  through  a  Concept  Action  Group  (Cl  6). 

The  development  of  the  estimate  at  this  time  should  be  the  baseline  for  future  estimates,  and 
except  for  (hopefully)  minor  updates,  reflect  the  program  estimate  (D71 )  to  be  submitted  for  the 
Milestone  I  decision  reviews.  However,  while  this  estimate  should  be  based  on  the  program  to  be 
recommended  at  the  Milestone  review,  there  may  be  a  requirement  for  the  generation  of  alternate 
estimates  or  excursions  to  support  the  decision  process.  These  additional  requirements  should  be 
directed  by  the  project  OPR  (CAG)  in  the  Operating  Command.  The  CAG  should  be  responsible 
for  working  issues  with  USAF  and  OSD  to  ensure  that  all  issues  are  resolved. 

(2)  The  need  for  performing  an  estimate  at  this  time  may  also  be  tied  to  the  ability 
to  establish  or  update  the  approv^  program  funding  levels  in  the  Air  Force  Program  Objective 
Memorandum  (POM).  Historically,  the  POM  call  to  AFMC  organizations  is  in  the  summer  of  each 
odd-numbered  year.  To  support  this  schedule,  the  project  team  should  plan  to  have  the  estimate 
complete,  and  approved  by  the  CAG  before  the  end  of  May. 

b.  Exit:  If  the  estimate  is  to  be  submitted  for  Summit  review  or  inclusion  into  the  POM,  it  must 
first  be  reviewed  and  approved  by  the  Project  Manager  and  the  CAG  in  the  Operating  Command  (C27). 
Note:  The  formal  estimate  discussed  here  should  not  be  confused  with  the  normal,  almost  continuous 
cost  analysis  and  estimating  that  is  performed  in  a  project  office.  However,  whether  a  "what-H"  or  formal 
estimate,  the  estimates  should  be  demented,  tracked,  and  archived  as  part  of  the  project  database. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  At  this  stage  of  the  project,  typically  only  limited  technical  and  programmatic 
information  is  available.  However,  to  derive  a  comprehensive  (albeit  top  level)  estimate  of  total 
program  costs,  the  project  team  must  develop  a  baseline  program  content  which  can  be  estimated. 

This  information  should  be  consistent  with  CAG  direction,  the  Program  Database  (D49) 
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infonnation,  and  the  assumptions  and  data  utilized  in  the  COEA.  The  necessary  program 
information  would  include  the  system  description  (to  the  extent  possible),  development  and 
production  schedules,  quantities,  and  acquisition  and  support  strategies.  It  is  recommended  that 
the  programmatic  assumptions  be  documented  in  the  Cost  Analysis  Requirements  Description 
(CARD)  format.  Although  a  CARD  (D52)  is  only  required  documentation  for  ACAT  I  &  II  program 
reviews,  developing  a  CARD  at  this  time  should  provide  valuable  insight  into  areas  that  warrant 
further  analysis  for  any  program.  Moreover,  even  when  rat  mandatory,  the  development  of  a 
CARD  should  improve  both  the  quality  arKf  credibility  of  the  cost  estimate. 

The  source  for  program  description  information  should  be  functional  experts 
(engineering,  manufacturing,  contracts,  logistics,  test.  arKf  management)  and  Operating  Command 
persoruiel.  In  addition  to  providing  detailed  information  on  their  functional  areas,  these  experts  will 
need  to  support  the  cost  estimators  by  identifying  analogous  programs,  and  aiding  in  the 
development  and  justification  of  the  selected  esiirnatifig  relationshps.  The  results  of  the  concept 
definition  efforts  (D37B).  COEA  Comparative  Analysis  (D48).  Program  AHematives  Analysis  (D46). 
and  the  updates  to  the  Program  Database  (D49)  should  provide  information  on  potential  program 
alternatives.  This  information  should  be  useful  in  providing  necessary  program  information  which 
would  support  program  definition  for  the  purpose  of  developing  this  cost  estimate.  It  is  imperative 
that  senior  functional  personnel,  knowledgeable  in  both  program  acquisition,  and  the  specific 
program,  be  involved  in  this  program  planning  aiKf  estimating  support.  The  results  of  this  program 
definition  effort  should  be  well  documented  and  any  revisions  tracked.  (Note:  This  cannot  be 
overemphasized,  since  all  levels  of  Air  Force  management  will  require  tracking  between  program 
cost  estimates  provided  to  them.) 

b.  Output;  The  results  of  the  analysis  should  be  formally  documented  and  approved  by 
the  Project  Manager  and  archived  in  the  project  database.  The  documentation  should  include  all 
groundrules  and  assumptions,  and  any  programmatic  information  necessary  to  replicate  the 
estimate  and  fully  support  the  cost  relationships  used.  If  the  estimate  will  be  utilized  to  support  a 
budget  submission  or  be  published  outside  the  project  office,  the  documentation  must  should  be 
accomplished  in  accordance  with  ASDR  173-1.  If  the  program  is  anticipated  to  require  either  an 
AFSARC  or  DAB  review,  the  estimate  to  be  submitted  at  that  time  must  be  generated  in 
accordance  with  the  referenced  "Cost  Estimating  Documentation  Checklist'  and  the  "OPERATING 
AND  SUPPORT  COST  ESTIMATING  GUIDE."  However,  no  matter  what  the  ACAT  level  of  the 
program,  the  estimate  generated  here  can  be  expected  to  be  essentially  the  same  estimate  as  the 
Milestone  I  Program  Cosi  Estimate  (D71 )  -  hopefully,  only  minor  updates  will  be  required. 

Therefore,  it  would  be  prudent  at  this  time  to  ensure  that  the  estimate  satisfies  all  the  analysis  and 
documentation  requirements  that  will  be  required  to  support  the  Milestone  decision  process. 

c.  Follow-on  activities:  The  estimate  should  be  provided  to  the  Operating  Command  CAG 
for  review  and  approval  if  the  estimate  is  to  be  published  for  uses  other  than  project  planning 
within  the  project  office,  such  as  for  Summit  reviews  or  POM  submissions.  If  the  estimate  will  be 
used  to  support  an  Air  Force  Summit  review,  the  CAG  should  ensure  the  estimate  satisfies  the 
directed  Summit  requirements,  and  is  consistent  with  the  COEA  analysis  and  results. 

10.  KEY  REFERENCES: 

a.  AFR  173-1 ,  The  Air  Force  Cost  Analysis  Program,  3  Oct  80  -  Establishes  the  Air  Force  Cost 
Analysis  Program,  specifies  objectives  and  functions,  arxl  assigns  responsibilities. 

b.  AFR  173-1 1 ,  Independent  Cost  Analysis  Program,  7  Oct  86  -  Identifies  requirements  for 
IrKfependent  Cost  Analysis  and  Program  Office  Estimates. 

c.  DODD  5000.4,  OSD  Cost  Analysis  Improvement  Group,  24  Nov  92  -  Specifies  the 
responsibilities  and  functions  of  the  CAIG. 
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d.  AF  Instnjction  10-601 .  Missic.i  Needs  and  Operational  Requirements  Guidance  and 
Procedures,  16  Feb  1993,  paragraphs  1 .3.10, 1 .4,  Attachments  1 , 2,  and  5  -  Provides  guidance  on 
the  CAG  and  COEA. 

e.  AF  Sup.  1/DoOI  5000.2,  Aug  92  (DRAFT),  Part  10A  -  Air  Force  cost  estimating 
requirements. 

f.  DoD  5000.4-M,  Cost  Analysis  Guidance  and  Procedures,  Dec  92,  Chapter  1  -  CARD 
preparation  instructions. 

1 1 .  IMPLEMENTATION  TOOLS:  ASC/FM  can  provide  infonnation  on  the  following  cost  analysis  aids 
and  tools; 

a.  The  AFSC  Cost  Estimating  Handbook.  Vol  I  (undated)  -  estimating  and  documentation 
information. 

b.  The  AFSC  Financial  Management  Han(ftX)ok.  Nov  92  update  -  financial  information. 

c.  ASC/FM  Cost  Workstation  -  a  computer  automation  aid  and  application  tool. 

d.  The  ASC  Cost  Data  Center  -  historical  cost  data,  cost  models,  and  other  cost  related 
materials  and  references. 

e.  AFMC  Cost  Estimating  Handbook.  Vol.  II,  Aeronautical,  21  Sep  92  -  estimating  and 
documentation  information. 

The  following  should  be  referred  to  for  documentation  requirements; 

f.  SAF/FM  "Cost  Estimating  Documentation  Checklist,”  16  Nov  92 

g.  OSD  CAIG  "OPERATING  AND  SUPPORT  COST  ESTIMATING  GUIDE,"  May  1992. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  time  required  to  perform  and  document  an  estimate  must  be  planned 
based  on  the  specific  conditions  and  methodologies  chosen.  The  time  can  be  expected  to  vary  for  every 
estimate  depending  on  the  program  complexity,  data  availability,  and  the  size  and  experience  level  of 
the  estimating  team.  Early  in  the  program  life  cycle,  estimating  activities  are  typically  based  on 
parametric  analysis  and  should  take  2  to  4  months.  Again,  this  cani  be  considered  firm  -  the  time 
required  to  perform  and  document  an  estimate  must  be  planned  based  on  the  specific  conditions  and 
methodologies  chosen. 

b.  CONSTRAINTS:  The  greatest  limitations  in  the  performance  of  the  estimate  are  lack 
of  program  definition,  and  the  lack  of  relatable  historical  cost  information  .  If  sufficient  personnel 
aren't  assigned  to  accomplish  the  analysis  in  time  to  meet  the  required  schedule,  support  should 
be  requested  from  staff  home  offices  or  the  Program  Development  SPO  (ASC/XY). 

c.  RESOURCES:  The  estimate  is  usually  performed  by  one  or  two  cost  estimators, 
working  the  estimate  as  a  primary  duty.  Operating  and  Support  cost  estimating  support  from 
ASC/AL  may  also  be  required  if  fhe  project  office  does  not  have  the  in-house  capability  to  perform 
this  analysis.  Engineering,  logistics,  test,  and  program  management  personnel  should  be  formally 
assigned  to  the  estimating  team,  even  if  dedicated  only  part  time,  and  they  can  be  expected  to 
need  to  provide  40  -  80  hours  each  for  technical  suppoit.  Computer  assets  are  considered  a 
necessity  for  both  computation  and  documentation. 
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d.  LESSONS  LEARNED:  The  Cost  Staff  (ASC/FMC)  should  be  contacted  to  have  a  staff 
cost  analyst  focal  point  assigned  to  support  the  analysis  effort.  This  early  ASC/FMC  involvement 
at  the  initial  stage  of  the  estimate  should  help  get  buy-in  on  analysis  assumptions  and  would  be  a 
valuable  resource  in  data  searches  and  estimating  methodology  selectioi').  The  analyst  could  also 
be  a  valuable  aid  in  supporting  the  estimate  through  the  management  review  proems. 

Additionally,  the  cost  staff  may  be  able  to  assign  other  cost  analysts  to  generate  elemenis  of  the 
estimate,  or  perform  program  schedule  analysis.  It  should  be  expected  that  many  program 
variations  and  estimating  excursions  wilt  be  performed  to  support  the  decision  making  process, 
and  each  of  these  should  be  documented  arid  tracked  by  both  program  content  and  estimate 
results.  Failure  to  do  so  can  result  in  significaryt  rework  and  lo^  of  credibility.  This  estimate 
should  contain  a  comprehensive  track  to  the  prior  approved  estimate  (e.g.  DAt7),  and  any  other 
analyses  which  have  been  published. 

e.  BEST  PRACTICES:  In  building  this  cost  estimate,  it  is  expected  that  the  near-term 
activities  will  be  better  defined  than  the  long-term  effort.  In  preparing  for  a  Milestone  I,  a 
comprehensive  estimate  for  the  Demonstration/Validation  phase  should  be  generated,  while 
succeeding  phases  would  be  estimated  at  higher  levels.  In  all  cases,  effort  should  be  made  to 
incorporate  the  best  information  available.  Also,  the  cost  analyst  should  develop  a  comprehensive 
estimate  plan  which  defines  program  content,  describes  the  estimating  approach  and  the  estimate 
schedule,  identifies  estimate  team  members  and  assigns  responsibilities,  and  identifies  estimate 
groundrules  and  assumptions.  The  management  approval  of  this  plan  should  ensure  the 
commitment  of  necessary  resources,  and  baseline  the  program  to  be  estimated.  Lack  of  a 
comprehensive  plan  may  result  in  unnecessary  perturbations,  rework,  or  schedule  slips. 

f.  TRAPS: 

(1 )  It  is  imperative  that  cost  analysts  identify  methodologies  and  data 
requirements  as  soon  as  possible  so  these  needs  can  be  made  known.  If  this  information  is  not 
available,  work-arounds  must  be  made  as  soon  as  possible  to  maintain  the  planned  estimating 
schedule.  Also,  it  is  essential  that  the  estimating  and  functional  team  members  be  carefully 
selected,  so  that  the  best  possible  analysis  can  be  perfonned  at  this  time,  and  a  sound  financial 
baseline  can  be  established  to  support  planning  activities. 

(2)  The  estimate  discussed  above  had  its  genese  in  the  COEA  analysis,  and 
during  the  milestone  reviews,  the  estimate  will  be  compared  to  the  estimates  for  the  other  COEA 
alternatives.  Due  to  this.  IT  IS  ESSENTIAL  that  any  changes  to  the  program  content, 
assumptions,  or  estimate  results  be  incorporated  into  the  COEA.  Failure  to  do  this  may  result  in 
insufficient  or  <x>ntradictory  information  provided  to  the  Milestone  decision  makers  and  a  possible 
delay  in  program  approval. 
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1.  ELEMENT:  054,  TBS  1.3. 1.3  (IFC  93-3) 

2.  ELEMENT  TITLE:  Develop  PreliiTiinary  Test  and  Evaluation  Master  Plan  (TEMP) 

3.  ELEMENT  OWNER(S):  USD(A)DTE.  DOT&E,  Project  Office 

4.  ELEMENT  STAKEHOLDER(S):  Project  Office.  US0(A)DTE,  DOT&E,  Operating  Command. 
Implementing  Command,  Product  Centers.  PEO.  OAC. 

5.  REQUIREMENT: 

a.  DoDI  5000.2.  23  Feb  91 ,  Part  8.  Policies  and  procedures  for  conducting  test  and  evaluation 
during  the  acquisition  process. 

b.  DoD  5000.2-M.  Feb  91 .  Part  7.  How  to  write  a  TEMP  and  format  for  a  TEMP. 

c.  AFR  80-14,  3  Nov  86  Test  and  Evaluation."  Outlines  policy  for  test  and  evaluation  activities 
during  development,  production,  and  deployment  of  systems  in  the  Air  Force. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  block  is  to  initiate  the  process  of  test  planning  required  for  the 
potential  program. 

b.  Objective:  The  objective  of  this  block  is  to  begin  the  development  of  the  TEMP  and  start  the 
process  of  planning  the  test  operations  for  the  project  and  potentially  for  the  program  in  order  to  have  a 
TEMP  approved  by  the  appropriate  offices  in  place  for  the  Milestone  review. 

7.  DESCRIPTION:  At  this  point  in  the  process  a  potential  program  is  being  identified.  The  project  is 
looking  into  the  potential  solutions  and  coming  to  an  initial  conclusion  on  what  the  preferred  concept  may 
be.  The  TEMP  is  to  be  written  on  the  preferred  concept  prior  to  the  Milestone  review.  The  TEMP  must 
integrate  numerous  project  /  program  documents  and  the  planning  team  to  draft  and  prepare  a  TEMP 
must  get  started  early.  The  test  community  must  get  involved  in  many  of  the  decisions  that  are 
essentially  program  decisions.  There  are  testability  issues  and  integration  issues  that  the  test  community 
should  ensure  are  addressed.  The  IFC  calls  for  the  TEMP  to  be  drafted  here  in  order  to  have  a  draft 
ready  for  the  roundtable  discussions  (D57). 

a.  A  TEMP  is  required  for  all  HQ  USAF  programs  directed  by  a  Program  Management  Directive 
(PMD).  It  may  also  be  required  for  an  information  systems  program  directed  by  an  Information  Systems 
Directive  (ISD).  The  TEMP  is  developed  to  integrate  critical  issues,  test  objectives,  evaluation  criteria, 
systems  characteristics,  responsibilities,  resources,  and  schedules  for  test  and  evaluation  (T&E).  The 
TEMP  is  viewed  by  most  in  the  acquisition  process  as  an  "executive  overview"  of  the  program.  Not  only 
does  K  pull  together  in  one  document  the  schedule,  cost,  and  performance  criteria,  but  it  also  addresses 
the  constraints  of  the  program  in  terms  of  resources  and  time.  The  TEMP  should  be  prepared  for  each 
Milestone  starting  with  Milestone  I,  and  then  updated  at  each  Milestone  review  and/or  when  a  significant 
program  change  occurs.  The  TEMP  will  get  more  detailed  as  the  program  matures.  Initially,  it  should 
idertify  broad  test  concepts,  tong  lead  resources  required,  and  as  much  cost  information  related  to  the 
T&E  requirements  as  possible.  This  will  allow  the  decision  makers  the  best  information  possible  upon 
which  to  make  their  determination  of  program  viability. 

b.  The  TEMP  documents  the  overall  structure  and  objectives  of  the  test  and  evaluation  program. 
It  provides  the  framework  within  which  to  generate  detailed  test  and  evaluation  plans  and  it  documents 
schedule  and  resource  implications  associated  with  the  program.  lAW  DoD  5000-2-M,  the  TEMP  should 
not  exceed  30  pages.  Appendix  A.  Bibliography,  Appendix  B,  Acronyms,  and  Appendix  C,  Points  of 
Contact,  are  excluded  from  the  30  page  limit  as  are  any  annexes  that  may  be  deemed  appropriate  by  the 
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DoO  component.  Copies  of  the  Mission  Need  Statement  (MNS),  System  Threat  Assessment  Report 

(STAR),  and  Operational  Requirements  Document  (ORO)  wHt  submitted  with  the  TEMP.  Other 

documents  refwenced  in  the  TEMP  will  be  submitted  to  the  Office  of  Secretary  of  Defense  upon  request 

These  documents  will  be  submitted  by  the  program  office  when  directed  by  the  Milestone  Decision  * 

Authority.  There  is  also  guidance  put  out  by  the  Under  Secretary  of  Defense  for  Acquisition  that  states 

*the  MOEs,  MOPs,  and  criteria  in  the  ORD,  the  COEA.  the  TEMP  and  the  APB,  should  be  consistent," 

(measure  of  effectiveness  (MOE),  measure  of  performance  (MOP)).  A  sample  TEMP  is  corttained  in 

DoDM  5000.2M  Part  7.  Additionally,  the  TEMP  must  be  consistent  with  the  systems  en^neering  master 

plan  (SEMP),  which  contains  the  basis  for  the  entire  engineering  effort  and  lays  out  test  requirements  for 

various  asp^s  of  the  program.  The  SEMP  should  be  a  key  document  used  to  develop  the  TEMP.  The  • 

ORD  contains  a  requirements  correlation  matrix  (RCM),  which  is  the  basis  for  user-stated  needs  and 

requirements  and  is  a  required  part  of  the  TEMP. 

c.  APR  80-14  states  the  implenrieriiirig  command  is  responsible  for  preparing  and  coordinating 
the  TEMP.  The  Test  Director  within  the  Program  Office  is  the  person  ultimately  responsible  for  the 

preparation  and  approval  of  the  document.  0 

d.  A  TEMP  is  normally  developed  by  a  Test  Plan  Working  Group  (TPWG).  Initially,  the  SPO 
prepares  a  draft  TEMP  and  distributes  it  to  all  applicable  agencies  for  review.  It  is  then  discussed  at  the 
initial  Test  Plan  Working  Group  (TPWG)  meeting.  The  SPO  will  revise  the  document  as  required  after 
this  meeting.  All  test  participants  will  then  review  the  TEMP  again  to  ensure  all  requirements  are 
addressed.  The  participating,  operating,  supporting  and  Operational  Test  and  Evaluation  (OT&E) 

Commands  coordinate  on  the  TEMP  prior  to  submittal  to  higher  headquarters.  * 

e.  TEMPs  for  all  acquisition  category  I  programs  and  other  programs  designated  for  OSD  T&E 
oversight  will  be  approved  by  the  Director,  Operational  Test  and  Evaluation  (DOT&E)  and  the  Director, 

Test  and  Evaluation  (DTE)  who  works  for  the  Under  Secretary  of  Defense  (Acquisition).  Fifteen  copies 
of  the  preliminary  TEMP  are  submitted  45  days  (draft)  and  10  days  (final),  prior  to  the  Defense 

Acquisition  Board  (DAB)  Milestone  I  Committee  review  of  the  program.  For  programs  that  do  not  meet  a  * 

DAB,  15  copies  of  the  preliminary  TEMP  are  submitted  45  days  (draft)  and  10  days  (final)  prior  to  the 
Component  Milestone  Decision  ^jthority  review  board. 

f.  TEMPs  not  requiring  OSD  approval  will  be  approved  by  the  component  Milestone  decision 
authority.  Delegation  below  the  headquarters  level  is  authorized.  Coordination  of  other  participating 

MAJCOMs  is  required.  • 

g.  All  submitted  draft  and/or  Service  approved  TEMPs  shall  be  examined  for  completeness, 
accuracy,  and  consistency  by  elements  of  the  OSD  staff,  as  deemed  necessary  by  the  DTE. 

h.  A  TEMP  is  considered  approved  when  the  DTE  has  completed  the  OSD  coordinated  review, 

reconciled  all  OSD  and  coordinating  Component  commatxf  comments  with  service  interests,  arxl  • 

obtained  the  DOT&E  and  DTE  approval  signatures.  The  formal  response  objective  of  a  TEMP  approval, 
including  the  preliminary  plan  at  Milestone  I,  is  within  45  days  of  submittal  to  the  Director  Test  and 
Evaluation  (DTE)  by  the  DoD  component. 

i.  The  TEMP  must  be  updated  at  each  Milestone  review,  when  the  program  baseline  has  been 

breached,  or  on  other  occasions  when  the  program  has  changed  significantly.  Updates  may  be  made  by  ^ 

use  of  "correction  pages"  and  by  the  use  of  memorarKfa  indicating  "no  change." 

j.  Test  Plan  Working  Group.  (TPWG) 

(1)  The  TPWG  acts  as  a  forum  for  test  and  evaluation  (T&E)  related  subjects.  The 
TPWG  helps  draft  the  test  and  evaluation  master  plan  (TEMP).  In  acct^ance  with  AFR  80-14  ,  Section 
B.8,  the  iniplementing  command  forms  and  chairs  a  Test  Planning  Working  Group  (TPWG)  for  each  HQ  • 

USAF-directed  acquisition  program  that  requires  T&E.  For  smaller  programs,  only  one  TPWG  may  be 
needed:  for  large  scale  programs  (i.e.,  new  aircraft),  many  TPWGs  may  be  operating  concurrently.  The 
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TPWG  is  comprised  of  the  working  level  representatives  of  all  agencies  (RTOs,  PTOs,  Operational 
Commands,  centers  of  expertise,  contractors,  etc.)  participating  in  the  specific  test  effort  at  hand. 

TPWG  members  are  responsible  for  constructing  detailed  test  plans,  preparing  support  material  for 
technical  and  safety  reviews,  conducting  artd  monitoring  test,  reducing  arxf  analyzing  test  data, 
evaluating  results  and  preparing  test  reports.  TPWGs  convene  when  required.  Test  Managers  (TM) 
must  ensure  appropriate  planning  aixl  programming  has  been  dorw  to  enable  all  required  agencies  to 
participate  in  specific  TPWGs  for  the  duration  of  the  specific  test  effort. 

(2)  The  TPWG  should  be  formed  as  soon  as  the  MNS  and  STAR  are  developed  and  the 
ORD  is  drafted.  Many  times  the  program  is  not  yet  manrted  and  the  test  manager  is  forced  to  operate  on 
his/her  own  until  a  project  manager/project  team  is  established.  This  group  must  be  formed  in  time  to 
allow  for  early  and  thorough  test  planning  and  coordinating  with  proper  agerKies.  It  functions  as  long  as 
testing  is  planned  for  the  system  to  assist  in  updating  the  TEMP  and  to  monKor  test  progress.  The 
TPWG  should  continue  until  the  fxoject  is  terminated  or  all  testing  has  been  accomplished. 

(3)  The  TPWG  team  should  include  representatives  from  all  DT&E  agencies  external  to 
the  SPO  that  may  be  involved  during  the  life  of  the  project.  Based  on  anticipated  test  requirements,  the 
test  director  (TD)  will  establish  and  formalize  (perhaps  through  Memoranda  of  Agreement  or  contract) 
relationships  with  all  agencies  required  to  participate  in  DT&E  over  the  expected  life  cycle  of  the  system. 
The  agencies  represented  might  include  but  are  not  limited  to  developmental  test  centers;  laboratories; 
operational  commands;  operational  test  agencies/centers;  development  and/or  support  contractors;  Air 
Force  centers  of  expertise;  intelligence  agencies;  Army,  Navy,  Joint  or  other  government  agencies  (i.e.. 
NASA),  etc.  Ideally,  a  single  focal  point  from  each  participating  agency  will  be  identified  for  inclusion  on 
the  test  team.  Memoranda  of  Agreement  and  contracts  will  specify  exactly  what  is  expected  from  each 
agency  in  planning  for.  programming  for  and  conducting  system  DT&E.  The  TD  may  need  to  consider 
budgeting  for  support  for  some  agencies  which,  while  crucial  to  the  test  program,  have  severely  limited 
budgets.  When  these  agencies  and  representatives  have  been  identified  they  should  all  become  part  of 
the  TPWG. 

(4)  The  TPWG  must  accomplish  the  following  to  plan  the  test  and  get  the  project  going 

on  the  right  foot: 

Validate  test  requirements 
Develop  test  concepts 
Formulate  the  test  approach 
Plan  test  resources 
Develop  the  TEMP 

(5)  The  time  required  for  a  TPWG  varies  with  the  complexity  of  the  project.  It  could  be 
as  little  as  a  day.  to  as  much  as  several  months.  The  TPWG  typically  meets  once  a  quarter,  or  as 
required  as  you  approach  a  milestone  review.  Team  menfoers  include  all  functional  disciplines  that 
could  affect  the  design  or  test  of  the  system.  Additionally,  you  should  include  the  headquarters 
personnel  that  are  the  approval  authorities  for  the  TEMP.  The  TPWG  will  require  a  meeting  facility 
appropriate  to  the  security  level  of  the  project.  Further,  the  size  of  the  TPWG  will  dictate  the  facility 
requirements  for  the  meeting. 

k.  Test  Management  Council  (TMC) 

(1)  If  DT&E  program  scope  warrants  oversight  and  guidance  at  a  higher  than  the  working 
level,  the  TD  may  choose  to  establish  and  chair  a  Test  Management  Council  (TMC).  Typically,  a  TMC  is 
comprised  of  upper  management  representatives  from  the  key  agencies  involved  in  system  DT&E.  The 
TMC  convenes  on  a  periodic  basis  (i.e.,  quarterly  or  semiannually)  to  review  DT&E  program  progress  in 
relation  to  overall  program  goafs  and  obj^ives.  If  contractor  involvement  in  the  TMC  is  desired, 
appropriate  contractual  provisions  must  be  made.  Again  the  TD  may  need  to  plan  and  program 
resources  to  support  conduct  of  the  TMC.  TMC  participation  may  need  to  be  included  in  various  MOAs 
between  the  SFK)  and  agencies  participating  in  DT&E. 


8.  ENTRANCE/EXIT  CRITERIA; 

a.  Entrance:  The  TEMP  is  a  summary  of  the  project/program,  ^  well  as  a  test  and  evaluation 
plan.  Therefore,  most  of  the  planning  for  the  program  must  be  accomplished  (at  least  in  parallel)  prior  to 
final  TEMP  preparation.  TEMP  preparation  should  begin  as  eady  as  possible.  The  actual  TEMP  is 
prepared  prior  to  the  DAB  review,  when  sufficient  information  is  obtained  to  complete  the  TEMP.  This 
normally  irKludes  information  from  the  ORO,  MNS,  SEMP,  STAR,  and  the  cost  and  operational 
effectiveness  analysis  (COEA).  Exit  criteria  are  when  the  TEMP  is  approved  by  DTE  and  DOTE  prior  to 
the  DAB.  The  TEMP  is  never  really  finished.  It  is  updated  whenever  major  changes  occur  in  the 
program  and/or  before  each  milestone  review.  Annual  updates  are  not  required 

b.  Exit:  The  exit  criteria  for  this  block  is  to  have  an  approved  TEMP  ready  to  be  delivered  to  the 
milestone  review  panel. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  For  purposes  of  the  I  PC  inputs  to  this  block  are:  C26  -  Staff  and  Coordinate  ORD  I 
(user).  D50  -  Develop  Preliminary  System  Threat  Analysis  (Repof1(  (STA(R));  D51  -  Develop  Preliminary 
Acquisition  Program  Baseline  (APB),  D37B  Conduct  Concept  Definition  for  Preferred  Altemative(s). 

Approve/Validated  STAR  •  must  be  reviewed  and  pertinent  threat  information  incorporated  into 
the  TEMP.  The  STA(R)  will  be  sent  to  the  review  board  with  the  TEMP  so  do  not  repeat  the  STA(R)  just 
put  appropriate  information  in  the  TEMP. 

Operational  Requirements  Document  must  be  updated  and  incorporated  into  the  TEMP. 

Cost  and  Operational  Effectiveness  Analysis  (COEA)  must  be  reviewed  and  be  consistent  with 
the  TEMP  (Block  D48). 

A  Formulated  Test  Team 
An  Established  TPWG/TMC 
Validated  Test  Requirements 
Initial  Test  Concept 
A  Formulated  Test  Approach 
A  Plan  for  Test  Resources 

b.  Outputs:  Output  from  this  block  is  to  D57  Conduct  Strategic  Roundtable. 

Output  products  are:  An  updated  test  strategy  for  next  phase  and  inputs  for  long  term  test  resource 
requirements  planning 

10.  KEY  REFERENCES: 

a.  DoDi  5000.2,  23  Feb  91 ,  Part  8.  Policies  and  procedures  for  conducting  test  and  evaluation 
during  the  acquisition  process. 

b.  DoD  5000.2-M,  Feb  91 ,  Part  7.  How  to  write  a  TEMP  and  format  for  a  TEMP. 

c.  AFR  80-14,  3  Nov  86  Test  and  Evaluation  ”  Outlines  policy  for  test  and  evaluation  activities 
during  development,  production,  and  deployment  of  systems  in  the  Air  Force. 

d.  AFR  55-43.  Ojntains  guidance  on  OT&E. 
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e.  Memorandum  from  the  Under  Secretary  of  Defense  for  Acquisition,  Mar  92,  S(A)tect  - 
'Implemernation  Guidelines  for  Relating  Cost  and  Operational  Effectiveness  Analysis  (COEA)  Measures 
of  Effectiveness  (MOEs)  to  Test  and  Evaluation Says  the  COEA,  MOEs,  and  the  TEMP  must  be 
consistent. 

11.  IMPLEMENTATION  TOOLS:  OSD  has  developed  software  that  aids  in  the  review  of  a  TEMP  prior 
to  submittal  to  OSD  for  approval.  This  software  is  called  the  Automated  Test  Planning  System  (ATPS). 
POC  is  OUSD(A)  /DT&E  DSN  225-4608.  Also  there  are  sample  TEMPs  available  in  the  resource  library 
at  YXP.  The  single  face  to  the  customer  organizations  in  AFMC  can  help  with  TEMP  plannirtg  and  will 
help  with  inputs  for  the  total  test  arxf  evaluation  planning  of  the  program. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  time  required  to  build  a  TEMP  varies  with  each  program.  There  is  no 
specific  guidance  for  this  activity.  Since  the  TEMP  must  be  consistent  with  the  ORD,  the  COEA,  and  the 
APB  it  is  wise  to  try  to  have  these  documents  in  hand  prior  to  the  final  TEMP  preparation.  Reality  tells 
us  this  is  unlikely.  The  next  best  thing  to  do  is  get  all  the  data  from  these  documents  in  as  final  a  form  as 
possible  (draft  if  nothing  else).  Then  get  the  key  people  who  put  these  documents  together  with  the 
TPWG  as  late  as  possible  and  finalize  the  TEMP  just  prior  to  submittal.  The  process  of  planning  a  test  is 
lengthy.  It  should  be  started  as  soon  as  possible  after  the  basic  program  is  defined  or  at  least  as  soon  as 
a  framework  for  the  program  is  developeid. 

b.  CONSTRAINTS:  There  always  seems  to  be  no  time  to  do  the  TEMP.  It  also  seems  that 
when  the  TEMP  is  being  written  there  is  a  lack  of  system  and  program  definition. 

c.  RESOURCES:  The  TEMP  should  identify  and  project  the  need  for  the  key  resources  needed 
for  the  life  of  the  program.  These  should  include  DT&E,  OT&E,  and  live  fire  test  and  evaluation.  Long 
range  T&E  resources  must  be  identified  to  ensure  they  are  in  place  when  the  program  needs  them. 

These  should  include  elements  of  the  National  Test  Facilities  Base  (which  incorporates  the  Major  Range 
and  Test  Facility  Base  (MRTFB),  capabilities  designated  by  industry  and  academia,  and  Major  Range 
and  Test  Facility  Base  test  equipment  and  facilities),  unique  instrumentation,  threat  simulators,  and 
targets.  As  system  acquisition  progresses,  the  preliminary  test  resource  requirements  shall  be 
reassessed  and  refined  and  subsequent  TEMP  updates  shall  reflect  any  changed  system  concepts, 
resource  requirements,  or  updated  threat  assessments.  Any  resource  shortfalls  which  introduce 
significant  test  limitations  should  be  discussed  with  planned  corrective  action  outlined. 

d.  LESSONS  LEARNED: 

1 )  Build  the  test  objectives  matrix  as  eariy  as  possible  -  update  it  often  -  it  can  be  used  to 
track  accomplishments  and  estimate  costs/resources/  etc. 

2)  There  are  14  review  agencies  at  OSD  for  documentation  review  prior  to  the  DAB. 
They  each  want  to  see  the  TEMP  and  use  it  as  an  executive  summary  type  document. 

3)  Software  and  hardware  are  integrated  in  every  paragraph  of  the  TEMP.  They  are  no 
longer  addressed  separately.  You  must  show  how  your  program's  test  plan  is  integrated  for  both 
hardware  and  software. 

4)  The  T&E  community  should  make  major  inputs  to  the  exit  criteria  for  the  acquisition 
decision  memorandum  (ADM).  Then  you  can  aim  the  T&E  effort  at  those  exit  criteria  and  answer  the 
questions  that  are  important  to  the  program,  rather  than  nice  to  know  information. 

5)  Before  you  buik)  the  test  plan,  you  must  determine  the  evaluation  criteria  (MOEs)  so 
you  can  then  determine  the  data  required  to  answer  the  evaluation  questions,  i.e.  do  your  evaluation  plan 
first,  then  your  test  plan. 


6)  Make  sure  you  invite  OOT&E  and  USD(A)DTE  to  the  TPWG.  Neither  may  not  come, 
but  should  still  be  invited.  Th^  will  appreciate  it  and  be  more  prone  to  look  favorably  at  your  TEMP 
when  they  must  review  it  prior  to  their  approval  process. 

7)  The  TEMP  should  be  consistent  with  many  documents,  including  the  SEMP  Included 
in  the  SEMP  should  be  a  discussion  or  at  least  an  acknowlec^ment  of  the  AFMC  Design  to  Test  policy. 

8)  The  test  community  in  the  early  portions  of  a  project/program  should  try  to  be 
involved  in  many  aspects  of  the  overall  planning  Some  suggested  activities  and  when  they  should  be 
accomplished  are  on  Attachment  1  of  this  data  sheet. 

Other  lessons  learned  that  apply  to  test  planning  and  TPWGs: 

1 )  Everything  that  is  done  at  the  start  of  the  program  affects  the  conduct  of  the  program 
(good  or  bad).  The  eventual  outcome  of  the  program  is  a  direct  result  of  the  initial  planning.  Your  inputs 
for  test  planning  at  the  beginning  of  the  program  will  set  up  numerous  activities  that  must  be  well  thought 
out  so  the  program  will  function.  Spend  lots  of  time  thirrking  through  the  test  resources  and  test 
objectives  at  the  start  of  the  program. 

2)  Make  sure  you  take  a  long  range  view  of  the  test  planning  process  to  ensure  that  the 
program  does  not  mn  into  problems  that  could  be  anticipated  at  the  outset. 

3)  The  test  community  (Test  Director  from  SPO)  must  review  every  major  program  input 
(document,  briefing,  etc.)  to  keep  the  program  on  the  road  to  a  testable  and  viable  system.  Many 
decisions  made  for  convenience  have  testing  implications. 

4)  The  SPO  test  director  must  make  it  their  job  to  be  the  test  conscience  at  all  phases  of 
planning.  For  example,  the  TD  should  make  sure  test  inputs  and  considerations  are  addressed  in  the 
RFP,  SOW.  CDRL,  User  Specs.  SEMP,  ORD,  ROM.  etc. 

5)  The  SPO  test  director  must  be  the  one  to  coordinate  early  with  outside  testing 
organization(s).  You  are  the  one  responsible  for  ensuring  adequate  involvement  by  the  folks  who  will  do 
the  test. 

6)  The  test  director  is  in  a  position  to  be  a  representative  of  both  the  users 
needs/desires  and  the  needs  and  requirements  of  the  test  community  who  will  be  the  first  to  do  the  work. 

7)  Make  sure  the  TPWG  has  inputs  from  the  SPO,  RTO.  Operating  and  Supporting 
Commands,  the  contractor  and  the  test  wing. 

8)  Test  considerations  should  be  folded  into  the  overall  Acquisition  Strategy  (Block 

D66). 

9)  The  TPWG  can  be  an  overwhelming  activity.  There  are  usually  numerous  people 
interested  in  the  activities  of  the  TPWG.  If  you  are  not  careful,  the  TPWG  will  get  too  big  and  function 
as  a  review  group,  not  as  a  planning  group.  Make  efforts  to  only  have  the  right  people  In  the  TPWG. 

The  Program  Manager  will  make  many  decisions  affecting  the  conduct  of  the  test  portion  of  the  system 
development.  Make  sure  all  these  program  decisions  are  factored  into  the  TPWG  to  keep  from  getting  a 
disconnect  between  the  program  manager  and  the  test  community. 

e.  BEST  PRACTICES:  Do  not  delay  in  drafting  the  TEMP.  Put  a  priority  on  keeping  the  TEMP 
up  to  date  and  ntaking  it  a  working  doa'ment  instead  of  an  historical  document.  Get  a  good  test 
manager  on  board  early. 

f.  TRAPS:  If  you  do  not  start  early,  you  will  not  produce  a  quality  TEMP.  If  you  only  grab  an  old 
TEMP  and  force  fit  your  program  into  it,  you  will  have  a  poor  TEMP.  If  you  try  to  do  the  TEMP  without 
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he^>  from  the  single  face  to  the  customer  test  organizations  and  the  gray  beartte  in  the  command,  you 
will  hawe  a  poor  TEMP. 
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1.  ELEMENT:  D55.  TBS  1. 3.2.1  (IFC  93-3) 

2.  ELEKKNT  TITLE:  Develop  Roundtable  Execution  Plans 

3.  ELEMENT  OWNER(S):  AFMC/XR  in  conjunction  with  Project  Leader/Manager/Director  (as 
appropriate).  (There  are  several  different  owners  for  the  various  subelements  of  this  data  sheet.  The 
iridividual  subelement  owners  are  listed  with  the  description  of  that  particular  subelement.) 

4.  ELEMENT  STAKEHOLDER(S):  •  All  Product  and  Logistic  Centers 

•  Functional  Home  Offices 

•  Center  XRs  and  ASC/YX 

•  System  Program  Offices 

•  All  AFMC  Laboratories 

•  All  Test  Centers 

5.  REQUIREMENT:  AFMC  Pamphlet  800-7,  20  Noverrrber  92  Integrated  Acquisition  Strategy  Process 
(section  B)  -  This  document  provides  the  catalyst  for  developing  the  overall  lASP  execution  plan.  The 
requirements  for  the  subelements  are  provided  with  the  description  of  that  particular  subelement. 

6.  PURPOSE  AND  OBJECTIVES: 

a.  PURPOSE:  The  AFMC  Integrated  Acquisition  Strategy  Process  (lASP)  was  established  to 
ensure  the  early  involvement  of  senior,  experienced  advisors  in  the  formulation  of  the  acquisition 
strategy  for  any  new  acquisition.  The  purpose  of  the  Roundtable  Execution  Plan  is  to  map  out  the  level 
of  this  top-down  involvement. 

b.  OBJECTIVES:  The  overall  objective  of  the  lASP  is  to  "ensure  that  a  sound,  disciplined, 
functionally  integrated  program  acquisition  strategy  is  developed  to  meet  the  users'  needs  within 
resource  constraints"  (AFMCP  800-7).  The  overall  objective  of  this  element  is  to  build  the  plan  for 
developing  the  project  acquisition  strategy. 

7.  DESCRIPTION:  The  development  of  a  Roundtable  Execution  plan  becomes  necessary  when  the 
operating  command  has  made  its  selection  of  the  preferred  concept  alternative  (C25)  and  the 
implementing  command  has  begun  its  effort  into  defining  that  preferred  concept  (D37r ,.  The  Integrated 
Acquisition  Strategy  Process  (in  either  the  full  or  tailored  form)  is  applicable  to  all  acquisitions  except: 

•  Basic  Research  and  Exploratory  development  (6.1  and  6.2  funds). 

•  Advanced  developments  (6.3A  funds)  that  are  less  than  $25  million  (FY90$). 

•  Technology  Transitions  (PRAM,  RAMTIP,  and  FACTS)  less  than  $5  million  (FY90$). 

•  Spare  parts  as  defined  by  AFR  10-601  and  repetitively  procured  items  that  do  not  involve 
design,  development,  artd  testing. 

•  Repetitively  procured  noncomplex  services. 

If  a  particular  project  or  program  does  not  fall  into  one  of  the  above  categories,  there  is  an  lASP  in  its 
future.  The  first  step  is  to  determine  if  there  will  be  executing  a  full-blown  lASP  or  a  tailored  version. 

A  full  lASP  is  required  for  all  acquisition  projects/programs  that  require  an  acquisition  strategy 
review  by:  1)  Defense  Acquisition  Executive  (DAE),  2)  Air  Force  Acquisition  Executive  (AFAE),  or  the  3) 
Program  Execution  Officer  (PEO).  All  other  acquisitions  (except  those  excluded  above)  should  plan  on 
having  a  tailored  version  of  the  lASP  but  a  full-blown  lASP  is  still  a  possibility-the  decision  is  up  to  the 
Project  Leader/Manager/Director  (as  appropriate). 

As  soon  as  the  Operating  CommarxJ's  basic  requirements  are  identified  and  the  Air  Force 
commits  resources  to  the  acquisition  effort,  the  assigned  Cognizant  Program  Decision  Authority  (AFMCP 
800-7  defines  that  individual  as  the  Program  Executive  Officer  (PEO),  Designated  Acquisition 
Commander  (DAC),  or  the  appropriate  Laboratory  Commander)  along  with  the  Project/Program  Manager 
determine  the  lASP  plan.  Elements  that  must  be  considered  in  the  tailoring  effort  include: 
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-  lASP  Entry  Point  -  Where  is  top-down  type  ot  involvement  necessary?  On  certain 
smaller  projects,  the  first  two  Roundtables  might  not  be  necessary  and  the  best  bet  is  to  go  straight  to  the 
ASP  (Acquisition  Strategy  Panel)  (D61 )  for  a  review  of  the  program  plan  and  acquisition  strategy  and 
then  follow-up  with  a  low  level  Operational  Roundtable  (D67)  to  ensure  your  documentation  tells  a 
consistent  story.  If  the  particular  acquisition  is  small  in  dollars,  but  somewhat  politically  sensitive,  it 
might  be  best  to  convene  a  Strategic  Roundtable  (057)  to  get  senior  guidance  (and  buy-in)  from  the 
beginning  and  then  skip  the  Tactical  Roundtable  (059)  (but  still  accomplish  those  tasks  within  the 
Project/Program  Office)  and  then  reconvene  at  the  ASP. 

-  lASP  Participants  (who  and  how  many)  -  This  task  is  going  to  be  a  critical  one  to  the 
lASP  Execution  Plan.  For  example,  on  a  $200  million  program  to  develop  and  procure  a  new  low 
observable  UHF  antenna  for  the  F-15  and  F-16  fleets,  including  the  Air  (>>mbat  (^mmand  Commander 
and  the  Air  Force  Acquisition  Executive  as  members  of  your  Strategic  Roundtable  is  probably  overkill. 
However,  if  planning  the  Strategic  Roundtable  for  a  $35  billion  NASP  (National  Aerospace  Plane) 

Derived  Vehicle,  make  sure  that  SL  least  this  level  of  senior  decision-making  participation  is  sitting 
around  the  table. 

-  Duration  of  Roundtables  -  The  $200  million  antenna  program  might  be  able  to  sort 
through  the  Strategic  Roundtable  topics  in  an  afternoon  on  relatively  short  notice.  The  NASP  Derived 
Vehicle  might  require  2-3  days  to  sort  through  the  same  topics.  To  ensure  the  right  group  of  participants, 
allow  for  quite  a  bit  of  lead  time. 

-  lASP  Schedule  -  Develop  a  plan  addressing,  not  so  much  the  exact  calendar  dates  for 
the  Roundtables,  but  the  interval  between  the  various  types  of  Roundtables  to  be  included  in  the  overall 
Roundtable  plan.  Six  months  or  more  between  the  Strategic  Roundtable  and  your  first  Tactical 
Roundtable  on  the  NASP  Derived  Vehicle  might  be  appropriate,  but  the  UHF  antenna  project  might  skip 
the  Tactical  Roundtable  and  go  to  the  ASP  in  3  months. 

It  is  important  to  understand  that  it  is  not  only  the  amount  of  money  involved  with  the  project,  (although 
it's  a  big  contributor)  that  determines  the  level  of  the  lASP  in  which  the  program  should  engage.  Such 
topics  as  political  sensitivities,  who  the  contractor  is,  who  the  customer  is,  program  risk,  and  a  host  of 
other  considerations  need  to  be  looked  at  by  the  Project/Program  Manager  and  the  Cognizant  Program 
Decision  Authority  need  to  work  out  during  this  task.  In  order  for  the  Project/Program  Manager  to 
adequately  prepare  for  this  planning  session,  he/she  needs  to  have  brought  together  key  members  of  the 
Project/Program  Team  to  pull  together  a  plan  for  executing  the  next  phase  of  the  project/program.  If  the 
project/program  is  heading  towards  Phase  II,  III,  or  IV,  it  already  has  an  approved  Acquisition  Strategy 
Report  (Annex  C  of  the  Integrated  Program  Summary  to  use  as  a  baseline),  but  if  entering  Phase  I,  this 
document  has  not  yet  been  developed  (or  if  it  has,  it  has  not  yet  been  approved).  At  this  point  consider 
the  documents  and  functional  plans  listed  below.  Building  a  'strawman'  for  each  of  these  relevant 
documents/plans  is  an  excellent  place  to  start  Phase  I  planning.  It  will  also  give  a  head  start  on  putting 
together  your  Int^rated  Program  Summary.  Below  is  a  very  brief  description  of  each  of  those 
documents/functional  plans. 

-  IWSM  (Integrated  Weapon  System  Management)  Master  Plan  -  This  plan  represents 
a  consolidation  of  the  Integrated  Program  Summary  (directed  by  DoDI  5000.2)  and  the  Weapon  System 
Master  Plan(WSMP)  (AFR  400-3).  This  plan  is  being  automated  so  it  can  be  prepared  from  an  existing 
and  computerized  database.  The  actual  format  for  this  plan  is  still  being  formalized  but  should  be 
available  by  Sep  1993.  The  primary  source  documents  for  drafting  the  initial  IWSM  Master  Plan  should 
be  AFMC  Pamphlet  800-60,  IWSM  Guide.  29  May  92,  and  the  Oct  92  version  of  the  IWSMP  handbook 
developed  by  AFMC/XRM. 

-  Schedule  --  When  referring  to  schedules  in  the  phase  planning  arena,  we  are  not 
referring  to  the  detailed  work  package  level  schedules  associated  with  work  breakdown  schedules.  The 
scheduling  task  referred  to  here  is  of  a  pr<^rammatic  nature.  It  will  include  the  major  tasks  that  need  to 
be  completed  in  the  next  phase  of  the  project/program  such  as  lASP  schedule,  milestone  decision  cycle. 
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and  ma)or  reviews.  It  is  time  phased,  unlike  the  SEMS,  and  needs  to  reflect  the  start  and  finish 
relationships  of  the  various  tasks  which  need  to  be  accomplehed  in  the  next  phase.  The  desired 
outcome  of  this  activity  is  an  estimated  duration  for  the  next  phase  with  a  roadmap  on  how  to  navigate 
through  that  Phase.  The  main  purpose  of  an  integrated  master  schedule  is  to  allow  the  manager  insight 
into  the  health  of  his/her  project/program.  A  secondary  use  of  the  schedule  is  as  a  quick  response  tool 
when  executing  any  of  the  numerous  "what  if  exercises.  The  best  tools  to  have  when  beginning  to  lay 
out  the  schedule  for  the  next  phase  of  the  project/program  are:  a  good  understanding  of  what  needs  to 
be  done  in  the  next  phase  and  a  large  dose  of  reality  and  comrmn  sense.  Make  sure  the  team's  best 
folks  working  the  initial  schedule. 

-  Risk  Management  Plan  (RMP)  -  This  plan  takes  a  hard  look  at  the  risk  involved  with 
the  project/program.  The  normal  approach  to  risk  management  is  three  pronged:  1 )  Risk  Assessment, 

2)  Risk  Analysis,  3)  Risk  Handling.  While  working  through  each  of  these  broad  areas  consider,  as  a 
minimum,  these  specific  proiect/program  risks:  Technical,  Programmatic,  Supportability,  Schedule,  and 
Cost.  Elements  of  your  Risk  Management  Plan  will  be  interwoven  throughout  the  other  functional  plans 
and  milestone  decision  documents.  The  best  place  to  start  when  you  begin  sketching  out  the  Risk 
Management  Plan  is  part  5,  section  B.  of  DoDI  5000.2  and  part  4.  section  E,  of  DoD  5000.2M.  Defense 
Systems  Management  College  also  has  an  excellent  textbook  in  this  area  entitled  Risk  Management: 
Concepts  and  Guidance.  This  should  be  required  reading  for  anyone  beginning  a  project/program  risk 
assessment.  A  third  source  of  information  is  the  20  Aug  92  AcouisitiQn  Risk  Management  Guide  This 
guide  needs  to  be  on  hand  for  your  Risk  Management  Plan  discussions. 

-  Program  Protection  Plan  (PPP)  -  At  this  point  in  the  project/program,  most  of  the 
major  security  issues  have  already  been  encountered.  The  Program  Protection  Plan  is  the  overall 
Operational  Security  Plan  for  the  project/program.  Some  of  the  items  to  be  considered  in  the  PPP 
include:  Essential  Elements  of  Friendly  Information  (EEFI),  security  capabilities  and  procedures  at  all 
the  facilities  involved  with  the  project/program,  security  classification  guide,  required  security  resources, 
etc.  Start  preparation  for  the  development  of  a  PPP  by  reviewing  the  project's  security  procedures  to 

•  date  and  refer  to  DoDI  5000.2,  part  5,  section  F.  Another  excellent  source  of  information  is  the  Standard 
Ooeratino  Procedure  tor  Development  of  a  System  Program  Protection  Plan  dated  1 2  Jun  91 . 

-  SEMP  (Systems  Engineering  Master  Plan)  --  This  document  describes  all  the  activities 
the  contractor  and  government  engineers  will  accomplish  to  meet  the  systems  engineering  criteria 
outlined  in  Military  Starxlard  499B  {MIL-STD-499B).  The  SEMP  covers  how  the  contractor  will 
accomplish  these  activities,  who  will  accomplish  them,  how  those  activities  will  be  controlled,  and 
technology  will  be  transitioned.  If  the  project  does  not  need  a  contractor,  describe  how  the 
project/program  team  will  accomplish  these  activities.  At  this  point  of  the  project/program  life,  it  is  not 
possible  to  put  a  lot  of  detail  into  this  plan,  but,  it  forces  the  team  to  ask  a  lot  of  critical  questions  about 
the  prograrn/project  (the  RFP,  the  proposals  themselves  and  a  myriad  of  other  bits  of  information  are 
needed  to  finalize  this  plan).  MIL-STD-499B  is  the  first  place  to  lo^  when  you  begin  considering  the 
SEMP. 


-  SEMS  (Systems  Engineering  Master  Schedule)  -  The  SEMS  is  a  top-level  tool  used  to 
measure  progress  towards  completion  of  the  systems  engineering  activities  outlined  in  the  SEMP.  The 
SEMS  includes  a  set  of  exit  criteria  for  each  of  the  systems  engineering  tasks  listed  in  the  SEMP  which 
must  be  successfully  met  prior  to  proceeding  to  the  next  task.  Despite  the  word  "schedule"  in  the  title, 
the  SEMS  is  not  a  time-line.  It  is  an  event  based  flow  of  activities.  Progress  towards  completion  is 
based  on  a  percentage  of  the  completed  systems  engineering  tasks,  not  on  where  the  project/program  is 
based  on  the  calendar.  Again,  MIL-STD-4%B  is  the  first  place  to  look  when  preparing  the  SEMS. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance  into  this  process  occurs  with  the  selection  of  the  preferred  alternative  (C25)  based 
on  the  COEA  (D48). 
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b.  Exit  criteria  have  been  met  after  developing  the  lASP  execution  plan  in  conjunction  with  a 
Cognizant  Program  Decision  Authority  and  assembling  a  very  basic  'strawman'*  for  the  key  functional 
plans.  These  functional  plans  will  be  developed  more  completely  as  part  of  the  Operational  Roundtable 
(D67)  if  the  project  follows  this  route  as  part  of  the  lASP  execution  plan  or  as  part  of  the  milestone 
decision  support  package. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs  include:  the  information  gathered  from  the  Program  Alternatives  Analysis  (D46),  the 
Preliminary  Acquisition  Program  Baseline  (D51 ),  and  the  Milestone  0  PMD  (B10). 

b.  Output  is  the  lASP  Execution  Plan.  This  plan  is  the  roadmap  for  entering  the  next  step  in 
the  lASP  process.  Normally,  the  next  stop  is  the  Strategic  Roundtable  (D57),  but  as  discussed  above 
several  other  options  are  possible. 

10.  KEY  REFERENCES:  AFMC  Pamphlet  800-7,  Integrated  Acquisition  Strategy  Process  Guide.  20 
November  1992.  The  key  references  for  each  of  the  sub-elements  were  cited  in  the  description  section 
discussing  that  particular  subelement. 

1 1 .  IMPLEMENTATION  TOOLS:  AFMC  Pamphlet  800-7  contains  several  attachments  with  samples 
on  how  different  projects/programs  might  tailor  the  full-blown  lASP  to  meet  their  needs.  These 
examples  include  the  recommended  entry  point  and  the  suggested  participants.  The  entire  lASP 
approach  is  relatively  new  and,  to  date,  there  are  no  automated  tools. 

12.  PLANNING  GUIDANCE: 

A)  DURATION:  The  time  required  to  develop  the  lASP  execution  plan  should  only  be  1  day  if 
you've  dorre  your  homework  ahead  of  time.  The  time  required  to  build  the  'strawman"  for  the  various 
functional  plans  depends  on  how  much  effort  you  put  into  it.  At  this  point,  your  goal  is  to  focus  the 
planning  team  on  the  size  of  the  task  ahead  of  them.  If  you  choose  to  build  a  detailed  functional  plan  at 
this  time,  plan  on  a  series  of  1  to  2-day  working  groups  for  each  plan.  If  you  elect  to  frame  the  plan  at 
this  time,  the  process  should  be  able  to  be  completed  in  a  single  2  to  3-day  working  session. 

B)  CONSTRAINTS:  Getting  the  time  on  the  calendar  of  your  Cognizant  Program  Decision 
Authority  will  be  the  only  real  constraint  you  have  for  developing  the  lASP  plan.  For  the  other  functional 
plans,  the  availability  of  the  right  functional  experts  in  your  project/program  offices  is  your  primary 
constraint. 

C)  RESOURCES:  The  only  resources  you  will  need  are  the  experts  from  each  of  the  key 
functional  areas  and  a  facility  appropriate  for  the  size  of  your  planning  team  to  conduct  a  multiday 
working  session. 

D)  LESSONS  LEARNED:  None  to  date. 

E)  BEST  PRACTICES:  The  entire  process  as  outlined  in  the  description  section  is  considered 
to  be  a  b^t  practice.  The  amount  of  effort  put  into  outlining  the  functional  plans  will  pay  big  dividends 
down  the  ro^.  The  entire  process  is  given  nx>re  credibility  if  you  involve  the  right  folks  in  this  planning 
session.  Don't  be  hesitant  to  go  outside  of  your  own  organization  if  you  feel  you  might  need  some  extra 
expert  advice.  A  good  place  to  look  is  to  an  organization  who  has  recently  gone  through  this  same 
exercise. 

F)  TRAPS:  There  is  a  tendency  for  the  smaller  projects/programs  (which  are  the  only  ones 
allowed  to  tailor  their  lASP  plan)  to  "over  tailor."  Take  a  long  hard  look  at  what  you  are  cutting  out  to 
save  a  little  time. 
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1.  ELEMENT:  D56,  TBS  1.3. 1.4  (IFC  93-3) 

2.  ELEMENT  TITLE:  Update  Systems  Threat  Assessment  (Report)  (STA(R)) 

3.  ELEMENT  OWNER(S):  DIA/DT-AS.  AFISA/INK  Project  Office 

4.  ELEMENT  STAKEHOLOER(S):  Product  Center  Director  of  Intelligence  (Dl),  AFiSA/INAA,  OIA/DT- 
AS.  AFIA/INK  Project  office.  AFMC/IN 

5.  REQUIREMENT 

a.  DoO  5000.2-M,  Feb  91 ,  Part  5.  Policies  and  procedures  lor  developing  a  STA(R) 

b.  DoDI  5(X)0.2,  23  Feb  91 ,  Part  4,  Section  A.  pg.  4-A-1 .  Defines  intelligence  support  required 
for  acquisition  programs. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  STA(R)  is  defined  in  block  D50.  Here  the  purpose  is  to  update  the  threat 
document  based  on  inputs  from  the  summit  process  and  make  any  changes  required  from  the  DIA 
review. 

b.  Objective:  The  objective  here  is  to  have  an  updated  threat  document  for  the  upcoming 
Milestone  review. 

7.  DESCRIPTION: 

a.  Following  the  summit  process  (B15)  and  validation  by  DIA  (A14)  the  STA(R)  must  be 
updated.  Then  the  updated  document  is  given  to  the  operational  Roundtable  for  ‘harmonization''  of  the 
required  documents  for  the  upcoming  milestone  review.  The  Director  of  Intelligence  (Dl)  is  responsible 
for  updating  the  STAR.  This  update  should  include  any  new  or  refined  data  pertinent  to  the  mission  of 
the  acquisition  program  under  consideration.  The  STAR  was  written  to  include  an  assessment  of  those 
projected  capabilities,  doctrine,  strategy,  tactics,  organization,  equipment,  and  military  forces  that  a 
potential  enemy  could  use  to  defeat  or  degrade  the  US  system  during  its  employment.  Any  updates  to 
these  threats  must  be  considered.  The  STAR  is  the  basic  authoritative  system  threat  assessment 
tailored  for  and  focused  on  a  major  defense  acquisition  program.  STARs  are  required  for  ACAT 1 C  and 
1 D  programs  and  for  major  modification  programs,  as  defined  by  AF  Policy  Directive  1 0-6.  It  will  be  the 
primary  threat  reference  for  the  Operational  Requirements  Document  (ORD),  the  Cost  and  Operational 
Effectiveness  Assessment  (COEA),  the  Integrated  Program  Summary  (IPS),  and  the  Test  and 
Evaluation  Master  Plan  (TEMP).  All  updates  to  the  STAR  should  be  forwarded  to  the  project  personnel 
responsible  for  these  do^ments. 

b.  When  the  Dl,  in  coordination  with  the  Project  Director  (PD),  Air  Force  Intelligence  Support 
Agency  (AFISA),  Defense  Intelligence  Agency  (DIA),  HQ  AFMC,  and  the  using  command  determine  the 
STAR  needs  to  be  updated,  the  Dl  organization  will  draft  the  updates  to  the  STAR,  or  administer  a 
contractor's  efforts  to  update  the  STAR.  ASC/FASTC/TAIA,  DSN  785-4285,  writes  and  updates  the 
STAR  for  programs  at  ASC.  In  this  case  the  STAR  is  updated  just  prior  to  the  major  review  cycle  prior  to 
a  Milestone  I  review.  The  STAR  was  written  to  support  the  preferred  concept(s)  and  should  be  updated 
to  support  the  current  preferred  concept(s)  selected  by  the  MAJCOM  following  the  development  of  the 
COEA  for  Phase  0.  Only  one  STAR  is  developed  for  each  potential  program,  and  it  should  be  based  on 
the  preferred  concept(s)  to  be  presented  at  the  Milestone  review.  This  is  the  time  to  take  the  final  best 
guess  of  the  preferred  concept  and  solidify  the  STAR.  The  STAR  should  be  able  to  support  more  than 
one  concept  if  they  are  similar.  If  more  than  one  concept  is  to  be  proposed  and  the  concepts  are 
radically  different  it  may  be  necessary  to  develop  separate  STARs.  This  would  be  a  unique  situation  and 
is  highly  unlikely. 
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c.  The  intelligence  community  and  the  project  office  should  formally  agree  (via  MOA)  to  update 
the  STAR  prior  to  any  sifosequent  Milestone  reviews.  If  a  concept  action  group  (CAG)  has  been  fomned. 
they  should  notify  the  appropriate  intelligence  agericy  when  the  STAR  or  STA  requires  updating  or 
revision.  Specifically,  a  final  STAR/STA  is  required  when  the  milestone  review  is  imminent.  The  CAG 
should  be  the  ones  to  nr^ify  the  intelligence  folks  to  make  the  STAR/STA  final. 

d.  Remember,  any  changes  to  the  STAR  must  be  coordinated  with  DIA  and/or  AFISA  to  ensure 
they  agree  since  they  have  to  validate  the  STAR  prior  to  the  MSI  review.  (DIA  validates  the  STAR, 
AFISA  validates  the  STA.) 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  Several  documents  are  required  before  update  on  the  STAR  begins.  The  final 
Mission  Need  Statement  (MNS)  is  required  from  the  Operating  Command  or  JROC  (Joint  Requirements 
Oversight  Council).  The  latest  version  of  the  Concept  of  Operations  is  required  from  the  Operating 
Command.  And  finally,  the  latest  Systems  Requirements  Description  (SRD)  is  required  from  the  SPO. 

b.  Exit:  A  revised  document  is  the  exit  criteria  for  this  block. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  Input  is  block  B15  -  Conduct  Requirements  Summit;  and  block  A14  -  Validate  STA(R) 

(DIA) 


'*J 


f 


Ar. 


9 


9 
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b.  Outputs:  Output  is  to  bfock  067  -  Conduct  Operational  Roundtable,  and  block  A14  Validate 
STA(R)  (DIA).  in  addition  to  these  direct  input/output  blocks  refer  to  block  D50  -  Develop  the  STAR. 

10.  KEY  REFERENCES:  AFSCR  200-3,  Threat  Assessment  Documentation,  Atch  1 , 5  April  1985. 
Describes  how  to  write  a  threat  assessment. 

11.  IMPLEMENTATION  TOOLS:  The  STAR  will  use  the  Threat  Environment  Documents  (TEDs) 
developed  to  support  the  overall  MNS  to  derive  their  baseline  data.  All  other  relative  intelligence 
sources  will  be  used. 

12.  PLANNING  GUIDANCE: 


•  • 


Points  Of  Contact: 

Organization 

Commercial 

DSN 

HQ  AFMC/IN 

513-257-2869 

787-2869 

DIA/OTD-AS 

203-373-4740 

243-4740 

AFISA/INAA 

703-695-7578 

225-7578 

ESC/IN 

617-377-2377 

478-2377 

ASC/NAIC/TAIA 

513-255-4285 

785-4285 

a.  DURATION:  An  update  to  a  STAR  takes  time.  Normal  estimates  for  updates  are  from  1  to 
6  months  or  more. 


b.  CONSTRAINTS:  Data  may  be  limited  based  on  the  intelligence  data  base  pertaining  to  the 
specific  threat  and  system  under  consideration. 

c.  RESOURCES:  Normally  the  same  person  who  was  put  in  charge  of  developing  the  STAR 

should  be  pul  in  charge  of  updating  it.  Numerous  (2  to  10)  additional  personnel  will  be  required  to  assist  • 

in  the  data  collection  and  report  writing. 
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d.  LESSORS  LEARNED:  The  STAR  is  to  be  submitted  to  the  reviewing  authority  to  determine 
the  relationship  between  the  mission  need  and  the  threat.  The  potential  program  should  play  its 
requirements  against  the  threat.  The  STAR  can  be  used  to  justify  program  changes,  slips,  etc.  The 
threat  data  in  the  STAR  must  match  that  used  in  any  analysis  (MNA,  MAA,  COEA)  or  the  analysis  data 
may  be  invalid. 

e.  BEST  PRACTICES:  Early  in  the  program  it  is  advisable  to  establish  a  working  group  to  work 
the  threat  assessment;  examples  are  a  Threat  Steering  Group  (TSG)  or  a  Threat  Working  Group  (TWG). 
(See  Block  D50.)  There  is  no  formal  r^uirement  to  have  a  TSG  or  a  TWG  to  update  a  STA(R). 
Common  sense  and  best  practices  indicate  that  a  working  group  of  this  nature  is  helpful.  Contact  the 
Product  Certter  as  soon  as  possible  if  you  need  a  STA(R). 

f.  TRAPS:  It  is  the  project  office's  responsibility  to  ensure  the  STA(R)  is  initiated.  Just  because 
a  PMD  is  issued  following  a  MS  0  review,  do  not  assume  that  the  intelligence  community  knows  about  it 
and  initiates  the  report.  It  is  advisable  to  contact  the  Dl  when  the  PMD  is  issued. 
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1.  ELEIIEMT:  D57,  TBS  1 .3.2.2  (IFC  93-3) 

2.  ELEIKNT  TITLE:  Conduct  Strategic  Roundtable 

3.  ELEMENT  OWNER(S):  AFMC/XRMP,  ASC/CYX 

4.  ELEMENT  STAKEHOLOER(S):  Program/Project  Manager  (PM),  Program  Executive  Officer  (PEO) 
(if  assigned),  Designated  Activity  Commander  (DAC),  Project  Team  (Cadre),  Rouruftabie  Members 

5.  REQUIREMENT:  AFMC  Pamphlet  800-7, 20  Nov  92,  Sections  A.4  and  B.6,  define  the  requirements 
for  the  Integrated  Acquisition  Strategy  Process  (I ASP)  and  Strategic  Roundtable 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  Strategic  Roundtable  is  to  ensure  senior  experienced  management  involvement 
early  in  formulating  the  initial  program/project  acquisition  strategy. 

b.  Objectives;  The  objective  of  the  Strategic  Roundtable  is  to  help  the  PM  formulate  a  sound, 
disciplined  initial  acquisition  strategy  by  giving  a  program/project  the  benefit  of  the  members'  expert 
acquisition  knowled^  and  advice.  Advice  from  the  Roundtable  members  will  help  the  PM  formulate  this 
preliminary  strategy  by; 

(1)  Identifying  constraints 

(2)  Balancing  objectives 

(3)  Setting  priorities 

(4)  Providing  timely  feedback 

(5)  Adding  vision 

(6)  Identifying  options 

(7)  Identifying  and  managing  risk 

7.  DESCRIPTION: 

a.  At  this  phase  in  the  overall  life  of  the  program/project.  Phase  0,  Concept  Exploration  and 
Definition,  is  being  conducted.  What  needs  to  start  now  is  to  lay  out  the  initial  strategy  for  corxAjcting  the 
next  phase  of  the  program/project  (Phase  I,  Demonstration/Vaiidation).  This  can  be  ctone  using  the  first 
step  in  the  Integrated  Acquisition  Strategy  Process  (lASP),  Strategic  Roundtable,  if  the  PM  and 
Cognizant  Program  Decision  Authority  decide  a  strategic  roundtable  is  required  (D55,).  The  Cognizant 
Program  Decision  Authority  is  usually  either  the  PEO,  DAC  or  Laboratory  Commarxler.  These  officials 
determine  the  I  ASP  plan,  including  whether  to  have  a  full  or  a  tailored  I  ASP,  the  duration  of  the 
Roundtables  and  the  types  of  participants,  etc.  These  items  are  flexible  since  the  lASP  guide  allows  for 
tailoring  of  the  process.  If  they  believe  the  current  strategic  guidelines  and  decisions  are  sufficient,  the 
Strategic  Roundtable  may  be  bypassed  for  a  Tactical  Roundtable  entry  to  the  lASP.  Or,  they  may 
decide  to  have  more  than  one  Strategic  Roundtable. 

b.  The  Strategic  Roundtable  is  comprised  of  the  most  senior  advisors,  whose  advice  is  provided  to 
the  Manager  of  a  new  progranvproject  when  he/she  has  only  the  operating  command  requirements  and  a 
preliminary  system  concept.  The  PM  briefs  Roundtable  I  members  on  the  operational  requirements  and 
program  vision,  and  the  participants  focus  their  experienced  perspective  on  a  wide  variety  of 
program/project  topics.  These  topics  include,  but  are  not  limited  to; 

(1)  system  relation  to  national  objectives, 

(2)  threat  considerations, 

(3)  program  objectives, 
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(4)  Integrated  Weapon  System  Management  (IWSM)  issues, 

(5)  test  resources, 

(6)  financial  and  contracting  issues, 

(7)  environmental  issues  and 

(8)  joirrt  and  international  issues. 

From  these  discussions  the  Roundtable  members  give  strategic  ^iidance  which  wiH  allow  the  PM  to 
develop  a  preliminary  acquisition  strategy  for  the  progranvproject.  This  guidance  is  recorded  and 
included  in  the  minutes  of  the  meeting.  The  secretariat  is  responsible  for  preparation  and  distribution  of 
the  minutes,  among  other  duties.  At  ASC,  the  Secretariat  is  ASC/CYX.  Program  issues  may  necessitate 
that  an  additional  Strategic  Roundtable  session  be  held,  smce,  as  stated  above,  the  lASP  can  be 
tailored.  For  ACAT  ID,  1C,  or  designated  programs  (major  programs),  the  suggested  Roundtable 
participation  consists  of  the  following; 

-  SAF/AQ 

-  PEO  (if  assigned) 

-  Product  Center/CC  (DAC) 

-  Test  Center/CC 

-  AF/TE 

-  SAF/AQX 

-  AFOTEC/CC 

-  AFMC/CC 

-  Single  Manager  (System  Program/Project,  Product  Group,  Materiel  Group  manager) 

-  Logistics  Center/CC 

-  Operating  Command/CC 

-  SAF/AQC 

-  SAF/AQ  (Mission  area  director) 

-  AFMC  Directors  (Selected) 

-  Other  personnel  determined  suitable  for  participation  by  the  Cogr\izart  Program  Decision  Authority  or 
PM  (e.g..  Chief  Executive  Officers  and  Office  of  the  Secretary  of  Defense  key  personnel  with 
advisement  of  SAF/AQ). 

For  ACAT  II,  III,  or  IV  programs  (less  than  major  programs),  the  membership  would  be  tailored 
accordingly.  At  ASC,  for  locally  conducted  Roundtables,  the  PM  and  Cognizant  Program  Decision 
Authority  (usually  the  ASP  chairperson)  will  determine  the  attendees  for  the  roundtable. 

c.  The  PM  is  the  major  player  in  this  Roundtable  process.  After  the  PM  has  met  with  the  Cognizant 
Program  Decision  Authority  on  how  the  lASP  is  going  to  be  corxlucted,  it  is  up  to  the  PM  to  prepare  for 
the  Strategic  Roundtable.  The  preparation  is  a  shared  duty  between  the  PM,  Program  Director,and 
PEO/DAC.  However,  in  reality,  the  PM  and  his  cadre,  with  the  assistance  of  the  secretariat,  do  the  up 
front  work  to  prepare  for  the  meeti.  g.  They  do  all  of  the  usual  things  prior  to  a  high  level  meeting, 
schedule  the  meeting,  invite  the  participants,  prepare  the  program  and  the  briefing,  take  minutes,  etc. 
The  programs  and  briefings  for  these  Roundtables  have  not  been  formally  structured.  Rexibility  is  built 
into  the  process  to  allow  the  managers  to  decide  what  needs  to  be  discussed  and  settled  at  this  point  in 
the  program/project.  For  less  than  major  programs,  the  PM  and  Cognizant  Program  Decision  Authority 
can  tailor  the  Roundtable  briefing  to  a  level  appropriate  to  the  characteristics,  phase  and  issues  of  the 
acquisition  program.  A  mandatory  agenda  item  for  the  last  (if  more  than  one)  Strategic  Roundtable  is 
discussion  and  determination  of  members  for  the  Tactical  Roundtable  (Roun^able  II). 

d.  In  addition  to  new  programs/projects  which  have  only  the  Operating  Command  requirement  and 
preliminary  system  concepts,  the  Roundtable  and  lASP  can  also  be  used  prior  to  major  program/project 
restructures  and  major  program  Milestone  reviews. 
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8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  This  activity  can  start  anytime  in  Phase  0  after  it  is  determined  what  product  center  will 
support  the  Operating  Command  determine  the  requirements  and  a  PM  is  named.  The  PM  and  the 
Cognizant  Program  Decision  Authority  then  decide  what  type  of  lASP  requirements  are  needed  for  the 
program/project,  when  to  conduct  the  first  roundtable  and  who  should  be  the  members  (D55). 

b.  Exit:  The  Strategic  Roundtable  activity  can  be  exited  when  the  members  have  given  the  PM  their 
expert  advice  on  the  initial  acquisition  strategy  for  the  program/project.  The  advice  given  should  satisfy 
the  objectives  listed  above  by  identifying  constraints,  balancing  program/project  objectives,  identifying 
optkMis,  setting  priorities,  identifying  and  managing  risk  and  adding  vision.  This  information  is  then 
transformed  by  the  PM  into  rough  draft  of  the  acquisition  strategy  report. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

(1)  Roundtable  execution  plan  information  (055) 

(2)  Select  Preferred  Atternative(s)  (C25) 

(3)  Operating  command  operational  infomiation  (Cl  9) 

(4)  Operating  command  requirements 

b  Outputs: 

(1)  The  output  of  this  activity  is  expert  advice  to  aid  the  PM  in  developing  the  acquisition 
strategy  for  the  program/project  (D58) 

(2)  The  information  will  also  be  used  as  a  basis  from  which  to  start  Roundtable  II  (Tactical) 

(D59). 

10.  KEY  REFERENCES:  In  addition  to  the  AFMC  Pamphlet  listed  in  the  "Requirements"  section  above, 
references  include: 

a.  The  Air  Force  and  AFMC  FAR  Supplements,  Parts  5307, 

b.  AFMC  Pamphlet  800-60,  Integrated  Weapon  System  Management  Guide,  1  Jul  92,  and 

c.  DOD  Directive  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb  91 , 
all  of  which  contain  guidance  on  acquisition  planning. 

11.  IMPLEMENTATION  TOOLS:  AFMCP  800-7,  lASP  Guide 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  estimated  time  for  a  Strategic  Roundtable  to  be  accomplished  is  anywhere 
from  a  two  to  four  hour  meeting  to  one  lasting  up  to  two  days,  depending  on  the  project  complexity. 
Meeting  rx>tification  should  be  issued  at  least  30  days  in  advance  of  the  meeting  and  mirwtes  should  be 
distributed  within  1 0  days  after  the  session.  If  there  is  only  one  rourKftable,  the  entire  activity  could  take 
the  better  part  of  two  months. 

b.  CONSTRAINTS: 

(1 )  The  availability  and  scheduling  of  high  level  personnel  to  attend  the  Roundtable. 

(2)  Not  having  a  high  enough  level  of  experience  available  to  offer  advice  to  the 
program/project. 
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(3)  Being  given  a  top-down  directed  schedule  that  does  not  allow  the  PM  enough  time  to  think 
through  all  issues. 

c.  RESOURCES:  Personnel  resources  for  the  Strategic  Roundtable  are  generally  not  broken  out  by 
function,  but  are  as  listed  in  *he  above  'Description.* 

d.  LESSONS  LEARNED: 

(1 )  The  Roundtables  are  difficult  to  set  up  -  trying  to  schedule  the  availability  of  the  high  level 
members  -  and  the  PM  should  initiate  scheduling  them,  in  conjunction  with  the  Secretariat,  ASC/CYX,  at 
least  60  days  in  advance  of  the  planned  meeting. 

(2)  The  program/project  needs  a  manager  or  director  who  will  make  the  Roundtable  members 
stick  to  the  decisions  that  have  already  been  made.  They  should  also  encourage  merT4>ers  of  the 
Roundtable  to  offer  advice  and  then  follow  it. 

(3) .  Since  this  is  a  new  role  for  most  of  the  Roundtable  members,  make  sure  they  know  they 
are  now  participants  in  the  acquisition  strategy  and  not  just  evaluators. 

(4)  Whoever  facilitates  the  meeting  needs  to  make  sure  the  discussions  stay  on  the  items  for 
that  meeting  -  not  decisions  that  have  been  made  previously  or  items  which  should  be  discussed  at  the 
next  Roundtable. 

(5)  ASC/CYX,  the  ASC  office  of  primary  responsibility  for  lASP,  has  a  lessons  learned 
database  which  should  be  checked  for  additional  lessons  learnt.  (DSN  785-7073) 

(6)  Do  not  rely  solely  on  the  secretariat  to  take  minutes  of  the  meetings.  The  PM  should  have 
a  team  member  take  notes.  The  secretariat  is  not  intimate  with  details  of  a  specific  project/program  arxf 
may  misinterpret  discussions  or  direction. 

(7)  Strategic  Roundtables  have  been  known  to  address  tactical  issues  without  being  presented 
V  ith  enough  background.  For  instance,  the  Strategic  Roundtable  may  decide  whether  to  compete  or  go 
sole  source.  This  ties  the  PM's  hands  too  soon.  By  being  prepared  for  a  "runaway"  Strategic 
Roundtable,  their  decisions  can  be  based  on  aspects  the  PM  considers  vital. 

e.  BEST  PRACTICES: 


(1 )  Select  the  members  of  the  Roundtable  who  will  add  the  most  value  to  the  program. 

(2)  Send  out  the  Roundtable  agenda  and  any  point  papers,  background  papers,  or  program 
documents  2  to  4  weeks  in  advance  of  the  Roundtable  meeting.  This  will  give  the  members  a  chance  to 
be  prepared  for  the  items  which  will  be  discussed. 

(3)  Be  sure  to  review  the  action  items  at  the  end  of  the  meeting.  This  is  a  great  opportunity  to 
task  high  level  particqjants  to  deliver  needed  information  (such  as  documented  evidence  of  need  date). 

f.  TRAPS:  The  PM  should  become  aware  of  other/hidden  agendas  which  will  be  brought  out  at  the 
meeting.  The  PM  should  see  if  the  PEO/DAC  is  aware  of  any  of  the  possible  topics  so  they  can  be 
prepared. 
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1.  ELEMENT:  D58.  TBS  1 .3.2.3  (IFC93'3) 

2.  ELEMENT  TITLE:  Develop  Acquisition  Strategy 

3.  ELEMENT  OWIER(S):  Program/Project  Manager  (PM),  ProgranVProject  Director,  Program 
Executive  Officer  (PEO)  (if  applicable).  Designated  Activity  Commarxfer  (DAC) 

4.  ELEMENT  STAKEHOLOER(S):  Integrated  Acquisition  Strategy  Process  (lASP)  Participants, 

Project  Team  Members  (Cadre).  ASC/CYX,  AFMC/XRMP 

5.  REQUIREMENT: 

a.  DOD  Directive  5(X}0.1 ,  Defense  Acquisition,  23  Feb  91 ,  Part  1  and 

b.  DOD  Instmction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 ,  Part  5,  both  discuss  acquisition  strategy  policy  and  procedure. 

c.  Federal  Acquisition  Regulation  (FAR)  Part  34.004,  Major  Systems  Acquisition  Strategy,  and 

d.  AFMC  FAR  Supplement  Section  5307,  Acquisition  Planning. 

both  contain  sections  which  discuss  the  requirement  tor  acquisition  strategy  and  planning. 

e.  AFR  70-14,  Acquisition  Strategy  Panels,  discusses  what  needs  to  be  developed  tor  an  ASP. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  is  to  develop  an  initial  strategy  which  will  start  the  program/project  in 
the  right  direction  with  the  aid  of  early,  senior,  expert  involvement. 

b.  Objectives:  The  objective  of  this  element  is  to  use  the  input  and  information  from  the  senior 
experts  which  were  members  of  the  Strategic  Roundtable  of  the  lASP,  plus  other  gathered  information, 
and  develop  the  initial  program/project  acquisition  strategy  to  meet  the  Operating  Command  needs 
within  resource  constraints. 

7.  DESCRIPTION: 

a.  This  effort  occurs  directly  after  that  described  in  D57.  Although  this  element  develops  the 
initial  acquisition  strategy,  developing  the  entire  program/project  acquisition  strategy  is  an  iterative 
process  and  becomes  more  definitive  through  each  of  the  successive  lASP  Roundtables  and  the 
Acquisition  Strategy  Panel.  The  purpose  of  developing  the  initial  acquisition  strategy  is  to  provide  an  Air 
Force  and/or  DOD-approved  roadmap  tor  the  PM  and  his/her  team  (cadre)  to  follow  in  executing  their 
program/project.  A  sound  acquisition  strategy  is  a  necessary  condition  for  a  successful  program/project. 
A  primary  goal  in  developing  this  initial  strategy  is  to  minimize  the  time  and  cost  of  satisfying  an 
identified,  validated  need  consistent  with  common  sense,  sound  business  practice,  and  the  basic 
acquisition  policies.  The  acquisition  strategy  should  be  sufficiently  developed  to  give  the  PM  adequate 
guidance  to  achieve  the  objectives  of  the  program/project  and  to  control  risk.  The  strategy  for  this  early 
phase  of  the  program/project  is  derived  from  the  recommendations  of  the  members  of  lASP  Strategic 
Roundtable  I  (D57).  The  strategy  should  comprise  various  aspects  of  the  program/project  including 
management,  technical,  resources,  contracting,  testing,  training,  deployment,  logistics,  support, 
conpetition  and  other  elements  critical  to  the  success  of  the  program/project.  The  acquisition  strategy 
should  also  consider  the  constraints,  objectives,  options,  priorities,  and  risks  of  each  of  the  above 
elements. 
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b.  This  initial  acquisition  strategy  evolves  into  the  first  draft  of  the  Acquisition  Strategy  Report 
(ASR)  and  begins  the  skeleton  of  the  Acquisition  Plan  (AP).  This  initial  strategy  is  what  will  lay  the 
groundwork  for  the  program/project  and  can  make  it  a  success  or  not.  It  should  always  be  kept  current 
since  it  will  be  used  by  the  members  of  the  Tactical  Roundtable  of  the  lASP  which  will  further  define  the 
program/project. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  entrance  criteria  is  the  guidarn^e  given  by  the  lASP  Strategic  Roundtable 
senior  experts  described  in  D57  after  they  have  discussed  all  the  aspects  of  the  project  strategy. 

b.  Exit;  Exit  criteria  for  this  element  is  when  the  project  office  (cadre)  has  prepared  the  initial 
acquisition  strategy  and  included  it  in  the  first  draft  of  the  ASR  and  the  AP. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  The  inputs  to  this  element  are  the  recommendations  made  by  the  Roundtable  I 
participants  regarding  the  various  aspects  of  the  program/project. 

b.  Output;  Output  irK:ludes  the  initial  acquisition  strategy  which  will  be  used  to  prepare  the  first 
draft  of  the  ASR  and  AP.  This  strategy  will  also  be  used  by  lASP  Roundtable  II  (Tactical)  members  as 
they  further  define  the  program/project  acquisition  strategy. 

10.  KEY  REFERENCES:  AFMC  Pamphlet  800-7,  Integrated  Acquisition  Strategy  Process  Guide,  gives 
guidance  on  what  minimum  information  should  result  from  Roundtable  I  to  be  us^  in  the  acquisition 
strategy. 

11.  IMPLEMENTATION  TOOLS:  None  Identified. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Developing  this  initial  acquisition  strategy  is  program  dependent.  It  could  take 
anywhere  from  3  weeks  to  3  months. 

b.  CONSTRAINTS: 

(1 )  Ever  changing  (acquisition)  policy  is  a  constraint  when  trying  to  estabHsh  an 
acquisition  strategy. 

(2)  ArxMher  aspect  programs  must  take  into  consideration  in  their  acquisition  strategy  is 
statutory  requirements.  ACAT I  programs  must  plan  for  competitive  prototype  development  of  a  major 
weapon  system  or  subsystem  (unless  a  waiver  is  granted).  Another  is  the  policy  of  using  cost  type,  in 
lieu  of  fixed-price,  contracts  for  development  programs.  And  a  recent  one  is  that  the  ban  on  Ozone 
Depleting  Chemicals  (ODCs)  must  be  taken  into  account  during  the  strategy  formulation. 

c.  RESOURCES:  The  PM  should  have  at  least  one  person  from  each  functional  area  available 
for  the  acquisition  strategy  planning  team  (cadre). 

d.  LESSONS  LEARNED: 

(1)  The  program/project  strategy  should  not  be  built  around  unrealistic  constraints 
directed  from  higher  levels.  These  constraints  should  be  discussed  during  the  review  where 
roundtable^anel  members  may  be  able  to  change  those  that  are  unnecessary  or  inappropriate. 
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(2)  Roundtable  recommendations  should  not  be  taken  as  mandatory.  A 
recommendation  which  says  look  at  it  again*  does  not  mean  it  should  automatically  be  changed. 

(3)  With  the  proliferation  of  reviews  for  a  new  program/project,  building  quality  into  the 
acquisition  strategy  will  save  scrsqs  and  rework  energy  later  in  the  program/project. 

(4)  ASC/CYX,  the  ASC  lASP  office  (DSN  785-7073),  has  initiated  a  lessons  learned 
data  base  in  addition  to  the  electronic  US  Air  Force  Lessons  Learned  Database  which  can  be  reviewed 
for  additional  information. 

(5)  Most  successful  starts  have  begun  with  will  defined  and  firni  requirements  and 
adequate  resources. 

(6)  Even  though  this  effort  is  accomplished  after  Roundtable  I  using  Strategic 
Roundtable  inputs,  it  should  really  begin  before  the  Roundtable  so  the  PM  can  present  pros  and  cons  of 
various  strategies. 

(7)  Involve  industry  in  all  applicable  areas  of  the  overall  strategy  process. 

e.  BEST  PRACTICES: 

(1 )  Get  input  from  senior  management  (Strategic  Roundtable).  They  are  the  ones  who 
will  give  the  PM  their  recommendations  from  which  he/she  develops  the  acquisition  strategy.  It  is 
important  that  senior  experienced  policy  and  decision  makers  be  on  the  panel  so  there  is  some  certainty 
that  recommerKfations  will  receive  support  as  the  program/project  progresses. 

(2)  Be  sure  to  check  the  latest  changes  to  acquisition  policy.  Ensure  all  statutory 
requirements,  (i.e.  prototype  competition,  fixed-price  development  contracts  approval,  ODCs,  etc.)  have 
been  considered. 

(3)  Ensure  there  are  enough  data  available  from  which  to  make  informed  decisions. 

f.  TRAPS:  Acquisition  strategy  represents  a  view  of  the  entire  program  and  should  not  focus  on 
the  instant  contract  activity.  Promises  made  early  in  an  acquisition  can  become  etched  in  stone. 
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1.  ELEMENT:  D59.  TBS  1 .3.2.4  (IFC  93-3) 

2.  ELEMENT  TITLE:  Roundtable  II  (Tactical)-Review  Draft  ASR 

3.  ELEMENT  OWNEFHS):  AFMC/XRMP 

4.  ELEMENT  STAKEHOLOER(S):  Project  Manager  (PM).  Program  Executive  Officer  (PEO), 

Operating  Comand. 

5.  I^QUIREMENT:  AFMC  Pamphlet  800-60,  31  Mar  93.  This  is  a  guide  for  implementing  the  IWSM 
for  all  programs  managed  by  AFMC. 

6.  PURPOSE/OBJECTtVES: 

a.  Purpose:  The  purpose  is  to  build  strategy  alternatives  within  timing  constraints  and  to 
complete  development  of  the  Integrated  Program  Summaries  (IPS)/Acquisition  Strategy  Report  (ASR). 

b.  Objectives;  Objectives  of  this  roundtable  are  as  follows; 

(1 )  Summarize  where  the  project  is,  versus  where  it  should  be. 

(2)  Describe  where  the  program  is  going,  and  how  it  wilt  get  there. 

(3)  Identify  project  risk  areas  and  plans  for  managing  risk. 

(4)  Provide  the  basis  for  establishing  explicit  project  cost,  schedule,  and  performance 

objectives. 

(5)  Roundtable  II  will  give  the  project  a  systematic  approach  to  completing  a  successful 
ASP  with  limited  manpower  of  today's  limited  resource  environment. 

'  DESCRIPTION: 

a.  The  Tactical  Roundtable  assists  the  Project  Manager  in  preparing  the  acquisition  strategy  for 
presentation  to  the  Acr^isition  Strategy  Panel  (ASP).  Discussion  topics  at  this  Roundtable  are  selected 
by  the  cognizant  decision  authority  and  the  project  team  to  facilitate  building  strategy,  alternatives,  and 
timing,  and  to  complete  development  of  functional  area  strategy.  The  project  team  d^ides.  if 
Roundtable  II  is  necessary  and,  in  rare  occasions,  may  go  directly  to  the  ASP. 

b.  Develop  Acquisition  Strategy  (D58)  includes  the  initial  acquisition  strategy  which  will  be  used  to 
prepare  the  first  draft  of  the  ASR.  This  strategy  will  be  used  by  lASP  Roundtable  II  (Tactical)  members 
as  they  further  define  the  program/project  acqi’'^ition  strategy. 

c.  Conduct  Requirements  Summit  (  B1 5)  considers  operational  concepts,  the  projected  threat,  and  the 
capabilities  of  other  supporting  systems  to  ensure  the  technic  '*!  solutions  under  d^elopment  meet  the 
user's  objectives.  The  requirements  review  and  scrub  at  this  Summit  has  a  greater  inpact  on  the 
success  of  the  program  than  any  future  Summit.  The  Results  are  fed  into  Roundtable  II  to  help  develop 
project  strategy. 

d.  The  Outputs  will  be  the  project  strategy  which  will  be  used  at  the  ASP.  This  strategy  is  Outlined  in  the 
'Acquisition  Strategy  Report  and  Draft  Milestone  I  Documents  &  Functional  Plans'  (D60). 
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8.  ENTRANCE/EXIT  CRITERIA: 

Entrance:  The  Tactical  Roundtable  is  convened  soon  after  the  project  office  prepares  the  first  c^aft  of 
the  Integrated  Program  Summary  or  Acquisition  Strategy  Report.  The  Project  Manager  (PM)  should  send 
out  an  agenda  and  meeting  notification  30  days  before  Rouridtable  II.  At  the  conclusion  of  the  first 
Roundtable,  'skeletons*  of  detailed  functional  plans  will  be  prepared  by  the  project  office.  With  these 
reports,  the  Project  Manager  will  develop,  with  the  participants  chosen  by  Rouriidtable  I,  the  strategy  tor 
each  functional  area  during  Roundtable  II. 

Exit;  At  the  end  of  Roundtable  II,  the  PM  will  document,  coordinate,  and  distribute  the  minutes  within 
10  working  days  of  the  meeting. 
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9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Input; 

(1 )  Develop  Acquisition  Strategy  (058) 

(a)  Minutes  from  Roundtable  I,  and 

(b)  The  regulations  outlined  in  requiremertts  above. 

(c)  Project  status 

(d)  Look  at  risk  areas  of  the  project. 

(e)  Also  look  at  the  project  cost  schedule  and  performance  objectives. 

(2)  Conduct  Requirements  Summit  (615) 

(a)  Looks  at  user's  requirements 

(b)  ensure  threat  assessment  is  current  with  user's  needs 

(3)  Output;  The  outputs  will  be  the  project  strategy  which  will  be  used  at  the  ASP.  This 
strategy  is  outlined  in  the  Acquisition  Strategy  Report  and  Draft  Milestone  I  Documents  &  Furxrtional 
Plans  (D60). 
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10.  KEY  REFERENCES: 

a.  AirForceRegulation70-l4,  Acquisition  Strategy  Panels,  14  Aug  92.  This  document 
discusses  acquisition  strategy  with  some  reference  to  Roundtable  II. 

b.  AFMC  Pamphlet  800-7, 20  Nov  92,  paragraph  7,  pg  5,  defines  the  requirements  for  the 
Integrated  Acquisition  Strategy  Process  (lASP)  and  Tactical  Roundtable. 

c.  Air  Force  Federal  Acquisition  Regulation  (FAR)  Supplement,  Part  5307, 1  Jan  92.  This 
document  gives  guidance  on  acquisition  planning. 

d.  HQ  AFMC/XRM  Ltr,  6  Aug  92,  Draft  AFMC  lASP  Guide,  Page  2,  Para  2.C.  Gives 
guidance  on  what  should  be  accomplished  in  the  rourxftable  process. 

e.  No  number.  Acquisition  Strategy  Formulation,  Mar  92,  covered  in  most  of  document. 

This  has  good  back  ground  information  on  the  roundtable  process. 

11.  IMPLEMENTATION  TOOLS:  Air  Force  Acquisition  Model  (AFAM) 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  Depending  on  the  complexity,  send  notification  to  aH  participants  30  to  60  days 
prior  to  meeting  date.  For  small  projects  it  will  be  a  1  day  meeting.  For  more  complicated  projects,  the 
process  could  require  as  many  as  10  meetings  during  a  2  month  duration,  and  for  major  projects  such  as 
an  F-22,  it  could  take  as  long  as  3  years  to  prepare  and  3  months  of  meetings  for  the  formal  roundtables. 
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b.  CONSTRAINTS:  Some  of  the  members  of  Rourxftable  I  need  to  be  members  of  Roundtable 
II  to  provide  continuity.  There  is  also  the  problem  of  too  few  people  doing  all  the  work,  but  some  of  this 
shortage  of  personnel  should  be  helped  by  using  the  roundtables  rather  than  going  directly  to  the  ASP. 

During  the  previous  early  acquisitions,  before  the  rourtdtable  process  was  conceived,  the  strategy  was  V 

developed  all  at  orx;e  during  the  ASP.  By  not  tunneling  the  strategy  in  incremental  steps  through  the 
Roundtable  process,  many  revisions  are  needed  which  used  up  great  amounts  of  manpower  needessiy 
Now  with  the  Roundtable  process,  strategy  will  be  developed  incrementally  and  more  efficiently. 

c.  RESOURCES:  Need  senior  members  from  the  Operating  Command  and  appbcable 

functional  areas.  A  project  team  is  needed  to  develop  project  strategy.  Airxxint  of  time  varies  * 

depending  on  complexity  of  project.  An  SAF/AQ  representative  from  Roundtable  I  should  be  at 
Roundtable  II  to  provide  continuity.  This  representative  should  be  picked  during  Roundtable  I 

d.  LESSONS  LEARNED:  The  functional  area  strategy  should  not  be  developed  before  the 
review.  Only  skeletons  of  the  strategy  should  be  developed.  CYX  is  developing  a  lessons  learned  data 

base  from  their  experiences  as  roundtables  are  completed.  * 

e.  BEST  PRACTICES: 

(1)  Some  participants  of  Roundtable  I  must  be  the  same  for  Roundtable  II.  Identify 

members  which  will  be  attending  Roundtable  II  at  Roundtable  I.  ^ 

(2)  Keep  in  mind  this  is  not  a  formalized  project  review  and  the  PM  should  not  go  in  to  it 
with  a  developed  functional  area  strategy.  The  functional  area  strategy  must  be  developed  during  the 
review. 


f.  TRAPS:  Do  not  develop  the  detailed  functional  strategy  before  Roundtable  II.  It  should  be 
developed  during  this  meeting.  It  is  not  wise  to  develop  strategy  which  does  not  fit  current  policy.  For 
example;  don1  go  in  with  a  recommended  3  level  maintenance  program  with  a  2  level  policy! 
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1.  ELEMENT:  D60.  TBS  1 .3.2  5/1 .3.2.6  (IFC93'3) 

2.  ELEMENT  TITLE:  Compleie  ASR  and  Draft  MS  I  Documents  and  Functional  Plans 

3.  ELEMENT  OWNER(S):  Project  Manager 

4.  ELEMENT  STAKEHOLOER(S):  HQ  USAF/XOR  .  OSD/PA&E,  SAF/AQ,  SAE.  Service  Secretary. 
Operating  Command.  Implementing  CommarKf,  Aeronautical  Systems  Center  (ASC)  Functional 
Organizations.  ASC/YX.  ASC/CYX,  HQ  AFMC/XRMP 

5  REQUIREMENT: 

a.  DoD  Directive  5000.1 .  Defense  Acquisition,  23  Feb  91 ,  Part  1 .  This  regulation  provides 
information  concerning  acquisition  strategies  and  program  plans. 
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b.  DoD  Instruction  5000.2.  Defense  Acquisition  Management  Policies  and  Procedures.  23  Feb 
91 ,  Part  2  and  Part  5  .  This  instruction  provides  information  on  the  Milestone  (MS)  review 
documentation  corKept.  risk  management,  and  acquisition  category  MS  documentation  requirements. 

6.  PURPOSE/OBJECTIVE(S): 

a.  Purpose:  The  primary  means  for  the  project  team  to  provide  the  Milestone  Decision  Authority 
(MDA)  with  the  information  neetM  to  make  a  Milestone  decision. 

b.  Objective;  To  ensure  the  draft  Acquisition  Strategy  Report  (ASR)  is  completed  based  upon 
guidance  provided  by  the  Tactical  Roundtable  II  (D59)  and  ready  for  A^uisition  Strategy  Panel  review 

f  arvf  possible  approval  (D61 )  so  that  the  Acquisition  Plan  may  be  completed  (D€6).  To  erasure  the  draft 
MS  I  documents  are  ready  for  review  by  the  Operational  Roundtable  ill  (D67). 

7.  DESCRIPTION: 

a.  In  every  acquisition  program  there  is  an  overarching  strategy  that  guides  the  project  called 
the  acquisition  strategy.  This  acquisition  strategy  is  contained  in  detailed  program  plans  that  the  project 
team  uses  to  manage  the  project.  Completion  of  a  draft  ASR  is  based  upon  guidance  provided  by  the 
Tactical  Roundtable  II  (D59).  This  Roundtable  assists  the  project  manager  in  preparing  the  acquisition 
strategy  for  presentation  to  the  Acquisition  Strategy  Panel  (D61 )  and  is  reflected  in  an  initial  draft 
Acquisition  Plan  (AP)  (D66).  The  AP  is  used  to  integrate  the  acquisition  strategy  in  a  single 
comprehensive,  coo^inated  plan  to  fulfill  the  government's  needs.  Alt  pertinent  MS  documents  and 
functional  plans  are  initially  drafted  prior  to  the  Operational  Roundtable  III  (D67).  These  plans  are 
brought  to  the  Operational  Roundtable  to  ensure  agreement  between  the  Rountable  participants  of  each 
document's  content  and  harmony  among  the  documents  as  a  whole.  Based  upon  guidance  from 
Roundtable  III,  the  draft  MS  documents  and  functional  plans  are  completed  arxf  finalized  (D68).  The 
MDA  is  provided  with  a  combination  of  the  plans  containing  essential  information  needed  to  make 
decisions  and  to  comply  with  statutory  requirements.  Finally,  during  the  execution  of  the  project  in  the 
phase  between  MS  decision  points,  the  project  team  provk)^  periodic  assessments  of  the  status  of  the 
project  accomplishments  against  program  plans  to  the  MDA. 

b.  The  Operatkig  MAXOM/CC  uses  the  results  of  the  Concept  Explot^bn  (CE)  Studies  and 
the  COEA  to  justify  and  select  a  preferred  alternative.  Working  with  the  acquisition  community,  a 
briefing  is  prepared  to  gain  CSAF  and  MDA  concept  demonstration  approval.  After  establishing  an  Air 
Force  position,  the  user,  implementer,  and  the  PEO  (or  Service  Acquisition  Executive  (SAE)  for  smaller 
programs)  prepare  the  documents  required  for  the  MS  I  review  (Concept  Demonstration  Ap^val).  The 
PMD  (B1 0)  should  have  assigned  tasking  for  the  applicable  documents.  The  number  and  types  of 
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documertis  and  amount  of  detail  will  vary  by  the  ACAT  level.  A  Defense  Acquisition  Board  (DAB) 
program  requires  approximately  10  major  documents.  SAF/AQ  approves  acquisition  program 
documents  before  seixfing  them  to  the  Joint  Requirements  Oversight  Council  (JROC)  and  the  DAB.  The 
HQ  USAF-approved  Operational  Requirements  Document  (ORD)  is  the  basis  for  all  follow-on  program 
documentation. 

c.  Documentation  must  be  prepared  prior  to  an  Air  Force  Systems  Acquisition  Review  Council 
(AFSARC)  (B9)(B24).  The  AFSARC  process  is  for  AFAE  review  of  ACAT  I  programs,  any  joint  program 
for  which  the  Air  Force  is  lead,  and  ACAT  ll-IV  programs  as  determined  by  the  Secretary  of  the  Air 
Force  (SAF)  or  the  Air  Force  Acqueition  Executive  (AFAE).  The  AFSARC  reviews  ACAT  I  (vo^ams 
prior  to  a  MS  decision  or  prior  to  program  review  by  the  SAE.  It  is  the  Air  Force  review  process  which 
reviews  all  program  documentation  prior  to  going  to  the  DAB.  The  AFSARC  functions  as  the  DAB  for  all 
Air  Force  programs  that  are  less  than  ACAT  I. 

d.  Acquisition  strategies  and  program  plans  shall  be  tailored  to  accomplish  established  program 
objectives  and  to  control  risk.  The  d^mentation  is  limited  to  that  required  to  support  the  purpose  of 
the  MS  review  and  to  that  required  by  statute.  The  scope  and  formalify  of  the  do^mentation  required 
to  support  the  purpose  of  the  review  depends  on  the  program  Acquisition  Category(ACAT). 

e.  Finalize  ASR:  The  ASR  is  Annex  C  of  the  Integrated  Program  Summary  (IPS).  It  describes 
the  acquisition  approach  to  include  streamlining,  sources,  competition,  anti  contract  types  throughout  the 
period  from  the  beginnirrg  of  Phase  I,  Demonstration  arxf  Validation,  through  the  end  of  production.  The 
final  draft  ASR  is  prepared  by  the  project  team  based  upon  inputs  from  Rourxftable  II  (Tactical)  (D59) 
and  the  ASP  (D61).  The  Roundtable  II  builds  strategy  alterrratives  with  timing  constraints  to  complete 
development  of  the  ASR.  They  assist  the  project  team  in  preparing  the  acquisition  strategy  for 
presentation  to  the  acquisition  strategy  panel  (ASP).  The  ASP  reviews,  improves  when  necessary  and 
approves  the  program  strategy.  MDAs  will  approve  the  acquisition  strategy  for  acquisition  category  I 
programs  (D58,  D59,  A15). 


Table  -  Documents  Required  for  Milestone  I  Decision  Review 


DOCUMENTS  REQUIRED  FOR  MS  1 

1  DECISION  REVIEW 

DOCUMENT  (format  in  DoD  5000.2-M) 

ACAT 

J_ 

II 

JU _ 

_jy 

Operational  Requirements  Document  (ORD) 

X 

X 

X 

X 

System  Threat  Assessment  Report  (STAR) 

X 

System  Threat  Assessment  (ST A) 

X 

X 

X 

Integrated  Program  Summary  (IPS) 

X 

X 

X 

X 

Program  Life  Cycle  Cost  Estimate 

X 

X 

X 

X 

Acquisition  Program  Baseline  (APB) 

X 

X 

X 

X 

Test  &  Evaluation  Master  Plan  (TEMP) 

X 

X 

X 

X 

Component  Cost  Analysis  (CCA) 

X 

X 

X 

X 

Cost  &  Operational  Effectiveness  Analysis  (COEA) 

X 

X 

X 

X 

Defense  Intelligence  Agency  Report  (DIA) 

0 

Intelligence  Report 

0 

0 

Joint  Requirements  Oversight  Council  (JROC)  Report 

0 

Integrated  Program  Assessment  (IPA) 

0 

0 

0 

0 

Independent  Cost  Estimate  (ICE)  Report 

0 

Acquisition  Decision  Memorandum  (ADM) 

0 

0 

0 

0 

X;  Prepared  by  Military  Dept/PM 

0: 

Prepared  by  OSD  Staff 
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f.  Narrative  explanation  of  MS  I  Documents; 

(1)  Operational  Requirements  Document  IQRD).  Identifies  minimum  acceptable 
performance  requirements  to  satisfy  the  operational  need;  also  includes  performance  objectives  that 
would  provide  operationally  meaningful  increases  ^  capability.  Prepared  by  user  or  user's 
representative.  DoD  5000.2M,  Part  3  contains  preparation  procedures  and  format  (C19  and  C26). 

(2)  System  Threat  Assessment  Report  (STARV  Documents  the  Miftary  Department  s 
threat  assessment  at  the  system  level.  Prepared  by  Component  Intelligence  Command/Agency. 

National  Air  Intelligence  C^er  (NAIC)  writes  the  STAR  for  ASC.  DoD  5000.2M,  Part  5  contains 
preparation  procedures  and  fomW  (D50.  D56). 

(3)  System  Threat  Assessment  ISTAI.  Documents  the  military  department's  threat 
assessment  at  the  system  level.  Prepared  by  the  Air  Force  Neliigence  Command/ Agency.  For 
procedures  and  format  requirements,  see  DoD  5000.2M,  Part  5,  as  ST As  are  formatted  lice  the  STARs 
(B11,  D50). 

(4)  Integrated  Prooram  Summary  flPSI.  The  IPS  will  be  addressed  more  thoroughly 
here,  since  it  is  the  primary  decision  document  used  to  facilitate  top-level  acquisition  MS  decision 
making  and  is  not  contain^  in  other  data  sheets.  The  purpose  of  the  IPS  is  to  provide  a  succinct 
integrated  picture  of  the  program  status  for  use  by  the  MDA,  supporting,  and  review  forums.  It  highlights 
the  status  of  critical  areas  and  plans  for  future  acquisition.  At  MS  I,  the  IPS  will  summarize  the  results  of 
Phase  0,  Concept  Exploration  and  Definition.  When  writing  the  IPS,  the  project  team  needs  to  identify 
and  provide  the  following  information: 

(a)  The  most  promising  concept(s)  to  be  carried  into  Phase  I,  Demonstration 
and  Validation,  for  demonstration  and  further  development,  arxf  the  reasons  for  elimination  of  alternative 
concepts. 

(b)  The  risk  reduction  efforts  to  be  accomplished  during  Phase  I. 

(c)  The  trade-off  decisions  to  be  made  for  MS  I,  and  recommended  to  be  made 

for  MS  II,  by  the  MDA. 

(d)  The  design  alternatives  and  trade-offs  to  be  evaluated  during  Phase  I. 

(e)  A  summary  of  the  program  life-cycle  cost  estimate,  independent  cost 
estimate,  affordability  assessment  and  proposed  concept  baseline. 


(f)  The  DoD  Component's  proposed  project  acquisition  strategy  and  any 

proposed  waivers. 

(g)  The  Acquisition  Strategy  Report  (ASR)  discusses  the  basic  acquisition 
strategy  being  pursued.  As  part  of  the  IPS,  it  summarizes  the  entire  planned  program  structure  from 
Demonstration  and  Validation  through  Production  and  D^loyment.  Requests  for  Proposals  (RFPs)  for 
the  Dem/Val  phase  may  not  be  released  until  the  MDA  has  approved  the  ASR.  The  ASR  is  not  to  be 
confused  with  the  Acquisition  Plan  which  describes  the  acquisition  strategy  only  for  the  current  phase. 
The  ASR  should  discuss  the  transition  of  critical  technologies  in  technology  demonstration  programs  to 
prototypes  and  engineering  development  models  including  line  proofing  of  low  rate  initial  production, 
plans  for  reducing  risk,  NonDevelopmental  Items  (NDIs),  evlutionary  acquisition,  and  preplanned  product 
inprovements  in  the  context  of  the  operational  requirements  and  the  management  approach  to  the 
acquisition. 

(h)  The  IPS  is  a  statutory  imposed  requirement  prepared  by  the  project 
manager.  The  final  IPS  approved  by  the  SAE  will  be  submitted  to  the  DAB  Executive  Secretary  no  later 
than  10  working  days  prior  to  the  DAB  Committee  review. 
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(i)  The  IPS  concept  will  be  used  by  the  DoD  Component  MDA  for  ACAT  1C,  II, 

III  and  IV  programs:  however,  the  documentation  content  should  be  appropriately  tailored  for  ACAT  II,  III 
and  IV  pro^ams.  DoD  5000.2M,  Part  4,  contains  preparation  procedures  arxf  toimat  (D58). 

(5)  Program  Life  Cycle  Cost  Estimate.  Documents  the  project  team  s  life  cycle  cost 
estimate  of  the  project.  Used  by  the  MDA  along  with  the  Component  Cost  Analysis  (CCA)  to  determine 
the  acquisition  program  baseline  cost  estimate  and  affordabilify  of  the  program.  This  plan  is  prepared  by 
the  project  manager.  DoD  5000.2M,  Part  15  contains  preparation  procedures  and  format  (D71). 

(6)  Acquisition  Program  Baseline  Aoreement  lAPB).  Documents  the  cost,  schedule,  I 

and  performance  baseline  agreement  between  the  MDA  and  project  team.  Prepared  by  the  the  project 

team.  DoD  50{X).2M,  Part  14,  contains  preparation  procedures  and  format  (D51). 

(7)  Test  and  Evaluation  Master  Plan  ITEMPI.  Lists  the  critical  developmental  test  and 
operational  test  objectives  and  outlines  the  testing  and  evaluation  approach  and  methodology.  Prepared 

by  the  project  team.  DoD  5000.2M,  Part  7  contains  preparation  procedures  and  format  (D54).  ^ 

(8)  Component  Cost  Analysis  tCCAV  Documents  the  Air  Force  Independent  Life-Cycle 
Cost  Estimate.  Prepared  by  the  Air  Force  (B21 ).  DoD  5000.2M.  Part  1 5  contains  preparation 
procedures  and  format 

(9)  Cost  and  Operational  Effectiveness  Analysis  fCQEAL  Analyzes  the  comparative  . 

cost-effectiveness  of  alternatives  at  MS  I  and  II.  At  MS  III  and  IV  it  is  updated.  Prepared  by  ' 

independent  Analysis  Activity.  DoD  5000.2M,  Part  8  and  AFMCP  73-1  contains  preparation  procedures 

and  format  (C21,  C2S,  D48). 

(10)  Defense  Intelligence  Agency  miAl  Intelligence  Report.  Validates  the  basis  for  the 
threat  in  the  Mission  Need  Statement  (MNS)  and  the  STAR.  Prepared  by  the  DIA  for  ACAT  ID  programs 

(AS).  ► 

(11)  Intelligence  Report.  Validates  the  basis  for  the  threat  in  the  MNS  and  the  STA. 

Prepared  by  the  Air  Force  Intelligence  Command/ Agency  (B6). 

(12)  Joint  Reouirements  Oversight  Council  (JROCI  Assessment.  Verifies  the  need  and 
confirms  that  the  proposed  performance  objectives  and  thresholds  to  be  contained  in  the  program 

baseline  satisfy  the  operational  need.  Prepared  by  the  JROC  (A1 6).  I 

(13)  Integrated  Program  Assessment  (IPAL  Summarizes  the  independent  assessment 
of  the  project.  Identifies  critical  areas,  issues  and  recommendations  for  the  MDA.  Uses  the  same  format 
as  the  IPS.  Prepared  by  the  Defense  Acquisition  Board  (DAB)  committee  staff  specialist  for  the 
committee  chairman's  signature.  It  represents  committee  findings  for  DAB  designated  programs  or 

documents  the  results  of  the  committee  review  (A21 ).  I 

(14)  Independent  Cost  Estimate  (ICEI  Report.  Documents  the  OSD  Cost  Analysis 
Improvement  Group  (CAIG)  Assessment  of  the  Air  Force's  Independent  life-cycle  cost  estimate  (CCA) 
and  provides  the  OSD  CAIG  cost  position  on  ACAT  ID  arx)  1C  programs.  Prepared  at  the  OSD  level  by 
Program  Analysis  and  Evaluation  (PA&E)  (A17). 

( 1 5)  Acquisition  Decision  Menrwrandum  (ADM).  Provides  the  decisions  of  the  MDA  * 

(including  approval  of  the  ASR  if  not  approved  prior  to  the  MS)  and  the  exit  criteria  for  the  next  phase  of 

the  project.  Prepared  by  DAB  Executive  Secretary  for  ACAT  ID  programs.  Prepared  by  AFAE's  Staff 
Executive  Secretary  for  ACAT  1C  programs  (A22). 
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g.  Functional  Plans  In  addition  to  the  documents  rec^ired  for  MS  reviews,  there  are  a  number 
of  functional  plans  used  by  the  project  team  during  the  execution  of  each  acquisition  i^se.  Some  of 
these  documents  are  not  reviewed  directly  by  the  MDA,  but  may  be  used  as  supporting  material.  They 
include  those  documents  used  by  the  project  office  to  actually  execute  the  proj^.  Scope  and  formality 
of  these  plans  vary  by  project  phase;  formats  for  some  may  be  specified  by  the  Air  Force. 

Table  2  -  Milestone  /  Functional  Plans 
FUNCTIONAL  PLANS 

Integrated  Weapon  System  Master  Plan  (IWSMP) 

System  Engineering  Master  Plan  (SEMP) 

Systems  Engineering  Master  Sch^ule  (SEMS) 

Risk  Management  Plan  (RMP) 

Program  Protection  Plan  (PPP) 

Integrated  Logistics  Supp^  Plan  (ILSP) 

Pollution  Prevention  Action  Plan  (PPAP) 

Nuclear  Certification  Plan  (NCP)  (if  necessary) 

Cost  Analysis  Requirements  Description  (CARD) 

Program  Management  Plan  (PMP)  (May  be  used  on  non-major  programs,  generally  not  used  on 
major  programs) 

System  Security  Master  Plan  (SSMP) 

Computer  Resources  Life  Cycle  Management  Plan  (CRLCMP) 


(1)  Integrated  Weapon  System  Master  Plan  flWSMPI.  This  plan  addresses  both  the 
acquisition  phase  and  the  evolution  and  sustainment  phase  of  a  weapon  system.  The  IWSMP  will  define 
the  weapon  system's  evolution  throughout  the  system  life  cycle.  It  will  be  agreed  to  by  the 
developer/supporter  and  the  customer  and  will  allow  coordinated  budgeting  and  tradeoffs  to  be  made 
with  full  knowledge  of  what  is  forecasted  for  the  future.  IWSMP  is  required  by  AFR  400-3,  Weapon 
System  Program  Management,  Jun  89.  It  has  been  recommended  that  the  IWSMP  be  completed  at  MS 
I  and  should  continue  throughout  the  life  of  the  project.  POC  is  AFMC/XRM,  DSN  787-7596. 

(2)  Systems  Enoineerina  Management  Plan  fSEMPI.  A  concise  top  level  technical 
management  plan  for  the  integration  of  all  systems  engineering  activities.  For  plan  development  see 
DODI  5000.2,  Part  6;  MIL-STD-499B  (draft).  Systems  Engineering,  6  May  92  (D20B,  D55). 

(3)  Systems  Engineering  Master  Schedule  ISEMSI.  A  top-level  process  control  and 
progress  measurement  tool  to  ensure  completion  of  identifi^  accomplishments.  The  SEMS 
accomplishments,  with  their  supporting  criteria,  shall  include  those  necessary  to  provide  critical  technical 
inputs  and  decision  data  into  engineering  (technical)  and  project  decision  points,  demonstrationE,  reviews 
and  other  identified  events.  For  SEMS  development  see  MIL-STD-499B  (draft).  Systems  Engineering,  6 
May  92  (D20B,  D55). 

(4)  Risk  Management  Plan  IRMPI.  Defines  how  risk  analysis  will  be  performed.  The 
purpose  of  the  risk  analysis  is  to  anticipate  the  significant  things  that  could  go  wrong,  develop 
contingerKy  plans  in  case  they  do  go  wrong,  and  estimate  the  cost  and  schedule  impact  for  each  area  of 
risk.  For  plan  development  see  DoO  Directive  5000.1,  Defense  Acquisition,  Part  1  (D37B,  D55). 

(5)  Program  Protection  Plan  fPPPI.  Identifies  essential  project  information,  technology 
and  systems  to  be  protected.  It  creates  a  management  plan  which  outlines  the  measures  that  need  to  be 
taken  by  the  project  manager  to  protect  the  system  throughout  the  acquisition  process.  For  plan 
development  see  DoD  Instruction  5000.2,  Part  5. 

(6)  Integrated  Logistics  Support  Plan  (ILSPL  Describes  the  concepts,  resource 
requirements,  tasks,  schedules,  and  subordinate  plans  associated  with  each  Integrated  Logistics  Support 
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(ILS)  element.  The  ILS  effort  encompasses  the  following  elements:  maintenance  planning:  manpower 
and  personnel;  supply  support;  support  equipment;  technical  data;  training  and  training  support; 
computer  resources  support:  facilities;  pa^aging,  handlirtg,  storage,  and  transportation;  design  interface. 
For  plan  development  see  AFLC/AFSC  Pamphlet  800-34,  Acquisition  Logistics  Management,  chapter  1 0, 
13  Apr  87;  AFR  800-8,  Integrated  Logistics  Support  (ILS  Program,  Atch  5,  Jun  86  (C19,  D20B). 


(7)  Pollution  Prevention  Action  Plan  iPPAPi.  This  is  a  new  plan  to  be  incorporated 
into  system  milestones.  The  plans  major  objectives  are  to  show  how  the  Air  Force  will; 

*  reduce  the  use  of  hazardous  materials  in  and  existing  weapon  systems 

*  reduce  the  use  of  hazardous  materials  arxf  waste  generation  at  installations  and  Government 

Owned  Contractor  Operated  (GOCO)  facilities 

*  acquire  state  of  the  art  pollution  prevention  technologies 

*  apply  new  technology  to  pollution  prevention,  from  outside  or  from  Air  Force  research 

*  establish  investment  strategy  to  furxf  the  pothJtion  prevention  program. 


The  policy  for  the  Air  Force  ban  on  purchases  of  Ozone  Depleting  Chemicals  (ODCs)  implentents  the 
National  Defense  Ai'‘horization  Act  for  Fiscal  Year  1993,  Title  III,  Section  326  (Public  Law  102-484  policy 
on  ODCs).  Effective  1  January  93  the  Air  Force  instituted  policy  on  the  purchase,  use,  and  management 
of  controlled  ODCs.  The  DFARS  and  AFFARS  on  implementing  Ozone  Depleting  Substance  (ODS) 
restrictions  arKf  purchase  bans  became  official  through  Air  Force  Acquisition  Circular  (AFAC)  92-29,  27 
May  93.  The  most  serious  implication  to  the  SPOs  from  these  regulations  are  the  following 
requirements:  Original  contracts  in  excess  of  $1 0  million  in  value,  with  modifications  or  extensions 
extending  1  year,  initiated  after  1  Jun  93  must  be  evaluated  for  the  elimination  of  ODS.  The  evaluation 
must  be  carried  out  within  60  days.  No  further  mod/ext  may  be  made  until  the  evaluation  is  complete.  In 
the  absence  of  additional  guidance,  many  programs  may  slip  while  meeting  these  requirements. 

ASC/EM  has  highlighted  these  SPO  concerns  to  the  AFMC  Pollution  Prevention  IPT.  Pollution 
prevention  is  to  be  institutionalized  into  acquisition  by  the  erxl  of  1994.  (See  Air  Force  Chief  of  Staff 
memo  ,  Air  Force  Ban  on  Purchases  of  Ozone  Depleting  Chemicals  (ODCs)  -  ACTION  MEMORANDUM, 
dated  7  Jan  93  and  ASC  Environmental  Protection  Committee  briefing,  15  Jan  93 


(8)  Nuclear  Certification  Fllan  (NCP)  fif  necessary).  This  plan  provides  overall  guidance 
and  policy  concerning  the  nuclear  certification  aspects  of  the  project  (if  applicable).  It  identifies  nuclear 
certification  and  safety  activities  that  must  be  accomplished  and  identifies  major  contributors  and/or 
responsibilites  of  the  participants  in  the  nuclear  certification  and  safety  projects.  It  scores  as  an 
integrated,  cohesive  plan  to  accomplish  the  required  nuclear  certification  tasks.  For  plan  procedures  see 
AFR  122-1,  The  Air  Force  Nuclear  Weapon  Surety  Program  and  ASC/ENS  Nuclear  Certification 
Handbook,  Feb  87). 

(9)  Cost  Analysis  Requirements  Description  fCARDL  The  CARD  describes  the 
complete  program  and  will  be  used  as  the  basis  on  which  the  project  office  and  Air  Force  cost  analysis 
teams  prepare  the  program  life-cycle  cost  estimates.  For  plan  procedures  see  DoD  5000.4-M  (D52). 


(10)  The  Program  Management  Plan  (PMPL  Certain  non-major  programs  may  use  a 
PMP  to  replace  all  the  functional  plans,  but  the  PMP  is  generally  not  used  on  major  programs.  This  plan 
shows  the  integrated  time-phased  tasks  and  resources  required  to  accomplish  each  task  specified  in  the 
PMD. 

(11)  System  Security  Master  Plan  (SSMPV  Outlines  the  procedures  and  actions 
required  to  design,  develop,  manufacture,  and  deploy  a  secure  weapon  system  that  will  inhibit  or  prevent 
overt  or  covert  ground  threat  action.  This  plan  may  be  tailored  into  the  SEMP.  For  plan  procedures  see 
MIL-STD-1785  . 


(12)  Computer  Resources  Life  Cycle  Management  Plan  (CRLCMP).  The  management 
approach,  decisions,  and  plans  associated  with  computer  resources  is  documented  in  the  CRLCMP. 
Computer  resources  include  hardware,  firmware,  software,  services,  support  services,  supplies,  and 
spare  parts.  This  plan  is  developed  in  conjuction  with  the  ILSP  to  ensure  software  supportability  is 
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properly  addressed  during  development.  The  plans  will  cross  reference  each  other.  For  plan  procedures 
see  DoD  5000.2,  Part  6. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  This  element  begins  with  the  completion  of  the  Tcictical  Roundtable  II  (D59). 

b.  Exit;  Completion  ot  the  final  draft  ASR  and  development  of  the  draft  MS  Documents  and 
Functional  Plans  containing  the  information  that  will  be  needed  to  make  an  MS  decision  is  the  exit 
criteria  for  this  element.  Using  the  results  of  this  element  the  project  team  proceeds  to  review  and 
approval  of  the  Acquisition  Strategy  (ASP)(061).  The  ASP  approves,  or  recommends  approval  of  the 
acquisition  strategy  and  commitment  of  resources  to  the  appropriate  decision  authority  (D61 ).  If  the  ASP 
has  changes  to  the  documents,  the  project  team  needs  to  reenter  this  element  (D66).  The  project  team 
continues  developing  the  AP  and  reconciling  it  with  the  ASR. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  Program  Management  Directive  (PMO)  (B10).  The  PM D  directs  development  of 
the  COEA  and  the  ORD  and  identifies  the  required  documentation  arid  schedule  considerations  for  the 
next  MS.  The  key  inputs  for  the  final  IPS/ASR  are  the  MNS;  the  results  of  the  Concept  Exploration 
phase,  the  ORD,  and  the  lASP  (D57,  D59,  D61,  and  D67). 

b.  Outputs:  The  documentation/information  needed  by  the  MDA  to  determine  if  the  results  of 
Phase  0  warrant  establishing  a  new  acquisition  program  and  approval  to  proceed  with  the  Dermnstration 
and  Validation  phase. 

10.  KEY  REFERENCES: 

a.  DoD  5000.2-M,  Defense  Acquisition  Management  and  Documentation  Reports,  23  Feb  91 . 
This  manual  contains  procedures  and  formats  to  be  used  to  prepare  MS  documentation. 

b.  AF  Instruction  10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,  16  Feb  93.  para  1 .4.  This  instruction  provides  information  on  Concept  Studies,  COEA.  and 
MS  Documentation. 

c.  HQ  Operating  Instruction  800-2  (draft).  Policy  and  Guidance  for  Preparing  Program 
Management  Directives,  1  Jan  93,  para.  IV.  This  section  contains  information  on  documents  such  as  the 
MNS,  ORD,  COEA,  TEMP,  STAR,  PPP,  APB. 

d.  AFMC  Pamphlet  800-7,  Integrated  Acquisition  Strategy  Process,  20  Nov  92,  Section  A.  This 
pamphlet  contains  information  about  the  Operational  Roundtable. 

e.  ASR  Guide,  DSMC,  July  1984.  This  guide  provides  lessons  learned  for  the 
approval  process. 

11.  IMPLEMENTATION  TOOLS: 

a.  In  document  preparation,  software  tools,  such  as  some  of  the  Defense  Systems  Management 
College  (DSMC)  models,  are  helpful  for  certain  specialized  tasks.  The  competition  evaluation  module  is 
used  in  evaluating  alternative  acquisition  strategies. 

b.  DSMC's  procurement  strategy  model  (PSM)  works  by  comparing  your  proposed  project  as 
you  compare  it  to  past  projects  stored  in  a  data  base.  It  eliminates  the  less  attractive  strategies  and 
produces  a  short  list  of  recommended  strategies  that  have  the  best  chance  for  meeting  the  Initial 
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Operating  CapabiMy  (IOC)  and  the  project's  cost  constraints.  The  model  also  allows  the  project  team  to 
examine  the  effects  of  changes  to  the  parameters  that  were  entered  to  describe  the  project.  For  more 
information  on  this  software  package,  contact  PMSS  Directorate/DRI-S.  Ft  Belvoir,  VA  22060-5426,  DSN 
354-4795/5783. 

c.  The  Consolidated  Acc^isition  Reporting  System  (CARS)  provides  an  automated  tool  for  the 
preparation  of  the  Selected  Acquisition  Reports,  Defense  Acquisition  Executive  Summary  and  the 
Acquisition  Program  Baseline  which  are  all  used  to  support  the  MS  Decision  Review  Process. 

d.  Systems  200,  Acquisition  Planning  and  Analysis,  is  a  course  offered  through  The  Air  Force 
Institute  of  Technology  (ART).  This  course  has  a  Program  Documentation  Module  which  provides  an 
overview  of  the  regulatory  requirements  for  completing  the  ASR. 

e.  A  Computer  Based  Training  (CBT)  software  package  is  available  from  ASC/ALL,  513-257- 
1995,  for  use  in  developing  the  ILSP. 

f.  A  networking  tool  such  as  a  limeline.  “ 

12.  PLANNING  GUIDANCE: 

a.  DURATION: 

(1 )  MS  documents  may  require  anywhere  from  8  weeks  to  8  months  to  prepare  from  the 
time  of  tasking.  Factors  such  as  complexity  and  coordination  cycle  or  level  impact  the  duration  time. 
Draft  MS  documents  are  due  to  OSD  59  days  prior  to  the  DAB.  The  MS  documentation  review  is  44 
days  prior  to  the  DAB  and  final  documents  are  due  to  OSD  24  days  before  the  DAB.  The  final 
documents  for  AFSARC  reviews  must  be  finalized  by  the  date  of  the  AFSARC. 

(2)  At  least  2  months  is  required  to  prepare  the  draft  IPS/ASR  for  the  documentation 
review.  Much  of  the  stand-alone  documentation  is  prepared  in  parallel.  The  final  IPS/ASR  is  submitted 
to  the  Defense  Acquisition  Board  (DAB)  Executive  Secretary  NLT 10  working  days  prior  to  the  DAB 
Committee  review. 

b.  CONSTRAINTS: 

(1 )  Restrictions  regarding  the  time  by  which  all  documents  must  be  completed. 

(2)  Restrictions  on  the  availability  of  needed  project  staff. 

(3)  Restrictions  on  the  availability  of  equipmem  or  facilities  needed  to  complete  the 
documentation  parage. 

(4)  Identification  of  other  organizations/individuals  with  which  you  must  interface. 

(5)  Restrictions  regarding  the  proper  format  in  which  the  documents  must  be  produced. 

c.  RESOURCES:  The  Project  Team  needs  resources  in  the  following  categories: 

(1)  Strategy  and  Documents  Development  Team  (Technical  Manager,  Business 
Manager,  Logistician,  Contracting  Officer,  User  Representative  and  a  representative  from  HQ 
USAF/XOR  to  address  rec^irements,  a  representative  from  the  Test  community.  Special  Consultants, 
Communicator,  Administrative  Personnel). 

(2)  Two  man  months  (typically)  is  required  to  prepare  the  IPS/ASR  and  usually  in 
parallel  with  the  remaining  documentation. 

d.  LESSONS  LEARNED:  The  following  are  from  the  DSMC  ASR  Guide; 
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(1)  Project  teems  should  thoroughly  address  risk  assessment.  This  is  one  of  the  most 
important  review/approval  considerations. 

(2)  Project  teams  should  ensure  that  the  acquisition  strategy  is  kept  current  by  using  a 
knowledgeable,  qualified  person  to  maintain  it  artd  by  using  modem  word  processing  equiprnem  to 
enable  rapid  updating. 

(3)  Project  teams  should  stay  in  constant  contact  with  Points  of  Contact  (POC)  in  OSD, 
Air  Staff,  Using  Command  to  coordinate  review  and  approval  schedules  for  all  documents. 

(4)  Project  teams  should  maintain  control  of  draft  document  changes  to  ensure 
consistency  of  information. 

(5)  The  MS  planning  meeting  is  critical.  It  establishes  groundnjies  and  delineates  what 
must  be  addressed. 

e.  BEST  PRACTICES: 

(1)  In  developing  the  required  documentation,  project  teams/initiators  should  keep  them 
as  brief  as  possible  to  depict  relevant  information,  without  adding  levels  of  detail  exceeding  that  required. 
For  nonmajor  (ACAT II  through  IV)  programs,  documents  such  as  the  ORD  and  COEA  may  be  tailored  to 
avoid  an  unnecessary  burden.  The  designated  MDA  will  direct  the  tailoring  of  documentation  and,  if 
proper,  waive  specific  documentation. 

(2)  Project  teams  must  collaborate  tailoring  with  PEO/DAC;  provide  a  continuity  of 
advisors/approvers;  have  strategy  before  plans;  surround  himseH/herseK  with  functional  experts,  and 
encourage  disciplined  team  building/consensus. 

(3)  When  preparing  MS  documents,  prefect  teams  must  review  and  affirm  user-stated 
needs,  and  the  adequacy  of  project  development  efforts  to  satisfy  those  needs  in  a  timely,  cost-effective 
manner. 

(4)  The  Project  teams  must  maintain  close  liaison  with  other  agencies  to  ensure  their 
preparation  activities  do  rxTt  impede  the  projects  planned  dates. 

(5)  Acquisition  strategy  is  often  driven  by  schedule.  The  Request  for  Proposal  (RFP) 
may  be  issued  and  sources  selected  for  the  next  phase  before  all  the  data  is  in  from  Phase  0.  This  can 
happen  in  any  phase  where  source  selection  decisions  may  be  made  without  adequate  performance 
data.  Advocate  realism. 

(6)  Point  of  Contact  for  MS  documents  is  SAF/AQXA,  DSN  225-5973. 

f.  TRAPS: 

(1)  The  ASR  is  not  to  be  confused  with  the  Acquisition  Plan  which  describes  the 
acquisition  strategy  only  for  the  current  phase. 

(2)  Constrain  plan  writers  -  do  not  permit  each  function  or  discipline  to  create  its  own 
ground  rules  and  generate  unconstrained  plans.  The  end  result  of  this  kind  of  approach  is  a  mass  of 
unrelated  data,  which  at  some  point  (usually  critical  to  the  schedule)  has  to  be  restored  and  repackaged. 
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1.  ELEMENT:  D61 .  TBS  1 .3.2.7  (IFC93-3) 

2.  ELEMENT  TITLE:  Acquisition  Strategy  Panel  (ASP)  Review  and  Approval  of  Acquisition  Strategy 

3.  ELEMENT  OWNER(S):  ASC/PK,  ASC/CY 


4.  ELEMENT  STAKEHOLOER(S):  ASP  membership  should  be  tailored  to  the  specific  acquisition 
depending  on  the  nature  of  the  project.  Mandatory  core  members  include  representatives  from  the 
requirements  and  using  activities,  legal,  engineering,  conr^roller,  and  contracting  communities. 
Representatives  from  test  and  evaluation,  logistics,  manufacturing,  quality  assurance,  competition 
advocate,  base  environmental,  safety,  bioenvironmental  and  medicaKoccupational  health),  or  other 
personnel  should  be  included,  if  appropriate,  considering  the  given  acquisition. 

5.  REQUIREMENT:  DODI  5000.2,  'Defense  Acquisition  Management  Policies  and  Procedures’,  Part 
1 1 ,  Section  C,  dated  23  Feb  91 ;  Air  Force  Regulation  70-14  dated  14  Aug  92,  'Accjuisition  Strategy 
Panels." 

6.  PURPOSE/OBJECTIVES; 

a.  Purpose;  An  ASP  is  a  standing  or  Ad  Hoc  panel  of  functional  experts  whose  purpose  is  to 
serve  in  an  advisory  capacity  by  reviewing  and  recommending  ac(|uisition  strategies  tor  a  specific 
product  or  service. 

b.  Objective;  The  objective  of  the  panets  review  is  to  assure  there  is  a  systematic  and 
disciplined  approach  toward  achieving  an  economical,  efficient,  and  effective  acquisition.  The  ASP  is 
convened  to  review  the  integrated  strategy  for  realism,  flexibility,  risk,  responsiveness  to  the  user's 
needs,  balance,  and  executability. 

7.  DESCRIPTION:  An  ASP  should  be  requested  by  the  System  Project  Director  (SPD),  Project  Director 
(PD),  or  Project  Manager  (PM)  as  early  as  possible. 

a  The  acquisition  strategy  is  normally  briefed  by  the  Project  Director  and  the  Contracting  Officer 
to  representative  members  of  the  first  two  Roundtables,  usually  a  forum  of  Air  Force  Material 
Command's  (AFMC's)  most  senior  and  knowledgeable  acquisition  personnel.  The  ASP  will  be  chaired  by 
the  Program  Executive  Officer  and/or  the  Designated  Acquisition  Commander  (DAC).  This  panel 
provides  corporate  input  into  the  program  acquisition  strategy.  It  is  essential  that  the  experience  and 
viewpoints  of  AFMC's  acquisition  managers  be  applied  in  a  systematic  process  durirtg  tormulation  and 
selection  of  program  acquisition  strategies.  The  ASP  review  process  helps  to  ensure  such  expertise  is 
incorporated  into  the  acquisition  strategy.  The  results  of  an  ASP  are  documented  recommen^ions  by 
the  panel  on  how  to  proceed  with  the  acquisition.  The  acquisition  strategy  is  then  adjusted  and 
documented  in  the  Acquisition  Plan  by  the  Contracting  Officer. 

b.  An  ASP  will  be  conducted  for  each  AFMC  program  that  requires  an  Acquisition  Plan,  except 
for; 

(1)  6.1  and  6.2  funded  programs  (Budget  Program  Activity  Codes). 

(2)  recurring  requirements  for  special  programs  under  AFR  800-29  where  a  class 
Jusfification  and  Approval  has  been  approved. 

(3)  certain  replenishment  spare  parts. 

(4)  certain  repetitively  procured  items  or  services(see  AFMCR  800-25). 
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8.  entrance;  exit  criteria: 


a.  Entrance:  The  ASP  is  held  after  the  Rouncftable  ll(  Tactical  Roundtable,  if  applicable,  Elemertf 
D59)  and  before  RouixJlable  lll(  Operational  Roundtable,  Element  D67). 

b.  Exit;  Exit  criteria  for  the  ASP  is  an  approved  set  of  minutes  which  sets  forth  the  panel's 
acquisition  strategy  recommendations. 

9  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  Functional  recommendations.  Operational  Requirements  Document,  Program 
Management  Directive,  and  Project  Director’s  draft  acquisition  strategy. 

b.  Outputs;  Acquisition  Strategy  Panel  minutes  and  Acquisition  Strategy  Panel 
recommendations . 

10.  KEY  REFERENCES: 

a.  AFMC  pamphlet  800-7,  Integrated  Acquisition  Strategy  Process  Guide,  dated  20  Nov  92. 

b.  Air  Force  Acquisition  Model,  (AFAM)  dated  3  Jul  1992. 

c.  A  Schedule  For  Acquisition  Planning;  Initial  Acquisition  and  Strategy  Development  Throu^ 
Source  Selection  (ASC/CYX),  dated  Dec  92. 

d.  ASC  Request  For  Proposal  and  Source  Selection  Lessons  Learned  Pamphlet  (ASC/CYX) 
dated  Jan  1993 


1 1 .  IMPLEMENTATION  TOOLS:  The  regulations  and  guidance  listed  above. 

12.  PLANNING  GUIDE: 

a.  DURATION:  The  ASP  meeting  will  typically  last  from  a  few  hours  to  all  day,  depending  on 
the  complexity  of  the  program  and  issues  involved.  Additional  meetings  may  be  necessary  to  resolve 
any  open  items/issues. 

b.  CONSTRAINTS:  Availability  of  appropriate  panel  members.  Trying  to  arrange  acceptable 
dates  for  senior  officials  is  often  very  difficult. 

c.  RESOURCES:  Need  members  from  all  functional  areas  and  the  Project  Manager  to 
develop  the  acquisition  strategy  to  be  briefed  to  the  panel.  Number  of  man-hours  to  develop  the 
acquisition  strategy  depends  on  the  complexity  of  the  program  and  may  range  from  l(X)-500  man-hours 
per  functional  area.  The  entire  effort  may  take  months.  The  Project  Manager  or  Contracting  Officer 
schedules  the  actual  briefing/review  of  the  acquisition  strategy  and  the  panel  review  normally  involves 
2-24  man-hours  per  functional  area. 

d.  LESSOfS  LEARNED:  We  should  guard  against  relying  too  much  on  reviews  and  too  little 
upon  building  in  quality  during  preparation.  That  initial  quality  must  come  from  having  adequate 
numbers  of  qualified  functional  personnel  supporting  the  program  office.  With  the  proliferation  of 
reviews~ASP,  Solicitation  Review  Board(SRB).  Source  Election  Management  Group(SSMG),  review 
relooks,  procurement  committee  review,  etc.-there  is  a  real  possibility  that  more  energy  is  applied  to 
reviewing  the  document  than  was  applied  in  the  original  preparation. 


e.  BEST  PRACTICES; 
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(1 )  For  the  purposes  of  a  more  efficient  and  thorough  review  of  the  acquisition  strategy, 
provide  a  draft  copy  of  the  Acquisition  Plan  and  RFP  a  week  in  advance  to  members  of  the  panel. 
Questions  may  then  be  addressed  and  answered  prior  to  the  ASP  meeting,  allowing  for  a  less 
cumbersome  and  lengthy  review  process. 

(2)  Selected  members  of  the  ^rategic  and  Tactical  roundtables  should  be  included  in 
the  Acquisition  Strategy  Panel  to  ensure  a  consistent  and  cohesive  acquisition  team  through  final 
approval  of  the  acquisition  strategy. 

(3)  Project  Managers  may  be  able  to  help  change  or  convince  senior  leaders  to  change 
those  unreaUstic  constraints  that  are  unnecessary  and/or  inappropriate. 

(4)  Use  this  opportunity  to  ask  for  waivers  and  delegations  since  the  right  people  will  be 
in  the  room.  Do^ment  the  minutes  to  show  approval. 

f.  TRAPS:  If  an  ASP  has  agreed  to  a  strategy  and  the  Program  Manager  later  receives 
additional  information  that  would  change  previous  decisions/recommendations  made  by  the  ASP.  the 
Program  Manager  should  coordinate  the  new  information  w4h  the  ASP  Chairperson  and  make 
appropriate  revisions  to  the  acquisition  plan  before  final  approval  of  the  plan. 

g.  METRICS: 

(1)  Acquisition  Strategy  approved  vs  failed  to  gain  approval, 

(2)  Action  Item  Tracking. 
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.  1  ELEMENT:  062.  TBS  1 .3.3.4  (IFC  93-3) 

^  2.  ELEMENT  TITLE:  Prepare  and  Appfove  Source  Selection  Plans  and  Standards 

3.  ELEMENT  OW»Cil(S):  ASC/CYX 

4.  ELEMENT  STAKEHOLOER(S):  Project  Manager.  Source  Selection  Authority  (SSA).  and  Source 
Selection  Evaluation  BoardH'eam 

5.  REQUIREMENT: 

a.  AF  Regulation  (AFR)  70-1 5/AFFARS  Appendix  AA.  27  Apr  88.  Formal  Source  Selectbn  for 
Major  Acquisitions,  and  applicable  supplements.  AFR  70-15  provides  policies  and  procedures  for 
coriducting  source  selections  for  major  acquisitions,  and  implements  Federal  Acquisition  Regulation 
(FAR)  Subpart  15.6.  Source  Selection  for  Major  Acquisitions. 

b.  AFR  70-30/AFFARS  Appendix  BB.  27  Apr  88.  Streamlined  Source  Selection  Procedures,  and 
applicable  supplements.  AFR  70-30  provides  streamlined  procedures  for  source  selections  which  fall 
below  the  dollar  thresholds  or  are  outside  the  scope  of  competitive  negotiated  procurements  described  in 
AFR  70-15. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpt^e:  The  Source  Selection  Plan  (SSP)  is  a  key  acquisition  document  that  specifies  how 
source  sele^ion  activities  will  be  initiated  and  conducted  for  an  acquisition.  The  SSP  serves  as  a  guide 
for  conducting  the  evaluation  and  analysis  of  proposals,  and  the  selection  of  source(s)  for  the  acquisition. 
The  evaluation  standards,  while  not  a  part  of  the  SSP.  are  used  during  the  source  selection  process  to 
enable  evaluators  to  measure  how  well  each  offeror's  approach  meets  the  requirements  of  the  Request 

^  for  Proposal  (RFP). 

b.  CX}jectives.  The  information  contained  in  the  SSP  reflects  the  decisions  and  strategies  for 
source  selection  as  agreed  to  by  the  Acquisition  Strategy  Panel  (ASP).  The  approval  of  the  SSP  by  the 
Source  Selection  Authority  (SSA)  indicates  the  plan  agrees  with  the  droisions  reached  at  the  ASP.  and 
the  approval  must  be  obtairred  prior  to  release  of  the  RFP.  The  evaluation  standards  nxjst  be  prepared 
and  approved  prior  to  the  evaluation  of  contractor  proposals  submitted  in  response  to  the  RFP.  and  the 
standards  must  be  written  in  such  a  manner  that  the  evaluator(s)  will  be  able  to  determine  the  strengths 
and  weaknesses  of  each  proposal.  The  use  of  the  evaluation  standards  by  the  source  selection  team 
ensures  the  selection  of  the  source(s)  whose  proposal  has  the  highest  degree  of  credibility,  and  whose 
performance  can  be  expected  to  best  meet  the  government's  requirements  at  an  affordable  cost. 

7.  DESCRIPTION: 

a.  An  SSP  is  required  for  all  competitive  acquisitions  corfoucted  under  AFR  70-1 5  or  AFR  70-30 
procedures.  The  plan  must  be  prepared  by  the  project  office  fo  sufficient  time  to  be  reviewed  and 
approved  by  the  ^A  prior  to  release  of  the  final  RFP.  and  to  allow  for  the  early  establishment  of  the 
source  selection  organization  (i.e..  SSA,  Source  Selection  Advisory  Council  (SSAC),  Source  Selection 
Evaluation  Board  (SSEB),  Performance  Risk  Analysis  Group  (PRAG),  or  Source  Selection  Evaluation 
Team  (SSET),  as  applicable).  To  ensure  consisterx^  among  the  various  documents  that  address 
acquisition  strategy,  ifs  recommended  the  project  team  begin  documenting  information  for  the  SSP  as 
soon  as  the  development  of  the  draft  RFP  begins.  This  early  documentation  ensures  all  relevant 
information  in  regard  to  the  source  selection  is  captured  in  the  plan  (i.e.,  instructions  to  offerors, 
evaluation  factors,  etc).  As  the  acquisition  cycle  progresses  and  the  project  team  obtains  additional 
information  pertinent  to  source  selection,  the  team  can  add  the  information  to  the  SSP,  or  revise  the 
information  already  contained  in  the  plan.  The  project  team  must  also  ensure  the  SSP  reflects  any 
decisions  or  strategies  agreed  to  by  the  ASP  in  reference  to  source  selection,  along  with  any  applicable 
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Program  Management  Directive  (PMO)  guidance  or  direction  prior  to  submitting  the  SSP  to  the  SSA  tor 
approval. 

b.  The  SSP  teelf  is  comprised  of  two  main  parts;  the  first  part  describes  the  actual  make-up  of  the  * 

source  selection  organization,  along  with  the  responsibilities  of  the  various  members,  and  the  second 
part  of  the  SSP  includes  the  evaluation  criteria  and  the  detailed  procedures  for  proposal  evaluation.  A 
typical  SSP  would  be  structured  as  follows:  however,  project  teams  are  advised  to  consult  the  source 
selection  regulations,  APR  70-1 5  or  APR  70-30  and  their  applicable  supplements,  prior  to  preparation  of 
their  SSP. 

> 

(1 )  Introduction  -  Provides  a  clear,  concise  overview  of  the  project  tor  which  the  source(s)  will 
deselected. 

(2)  Source  Selection  Organization  -  Identifies  the  proposed  membership  required  to  conduct 
source  selection  activities,  which  include  the  SSA  and  partic^nts  on  the  SSAC,  SSEB,  PRAG,  or 

SSET,  as  applicable.  Whenever  possible,  key  members  of  the  source  selection  organization  should  be  I 

identified  by  name,  and  position  title  or  functional  discipline  Participation  in  the  source  selection  process 
should  be  fimited  to  only  essential  personnel  consistent  with  the  complexity  of  the  project,  and  the 
proposed  team  structure  must  include  an  estimate  of  the  total  number  of  participanis. 

(3)  Proposed  Presolicitation  Activities  -  Describe  the  activities  leading  up  to  the  release  of  the 

solicitation.  This  section  includes  information  on  market  surveys.  Commerce  Business  Daily  I 

announcements,  or  other  methods  used  to  identify  potential  sources.  The  screening  criteria  used  in 

determining  the  qualifications  of  a  potential  source  must  be  ifKluded  in  this  portion  of  the  SSP,  along 

with  a  list  of  the  sources  identified.  Reference  to  the  ASP  and  any  draft  RFPs  will  also  be  included  in 

this  section  of  the  SSP. 

(4)  Evaluation  Procedures  -  The  specific  evaluation  and  rating  methodology  tor  proposals  are 

addressed  in  this  section  of  the  SSP.  This  includes  the  process  to  be  followed  in  formulating  the  ' 

government's  estimate  of  the  total  cost,  items  having  sufficiertt  cost  impact  to  warrant  special 

consideration,  and  items  that  represent  non-quantifiabie  cost  risks.  The  project  team  must  include  plans 

for  conducting  Independent  Cost  Analysis  (ICA),  Design-to-Cost  (DTC),  Most  Probable  Cost  (MPC),  or 

Most  Probable  Life  Cycle  Cost  (MPLCC)  estimates.  The  evaluation  procedures  portion  of  the  SSP  also 

provides  specific  guidance  to  proposal  evaluators  in  regard  to  documenting  the  ratings  and  risks  of  each 

proposal,  i.e.,  symbology  to  be  used,  color  codes,  and  risk  identifiers.  The  definitions  for  the  various  * 

methods  of  documenting  proposal  strengths,  weaknesses,  and  risks  must  be  taken  verbatim  from  APR 

70-15  or  APR  70-30,  as  applicable,  and  these  definitions  nniSt  be  inserted  into  the  SSP.  The  use  of 

Deficiency  Reports  (DRs),  Clarification  Requests  (CRs),  and  Modification  Requests  (MRs)  must  also  be 

discussed.  A  list  of  all  applicable  documents  and  briefings  associated  with  the  source  sel^ion,  along 

with  the  group  responsible  tor  that  item  must  be  documented.  The  project  team  must  identify  specific 

items  that  will  be  cited  in  the  RPP,  such  as  proposal  page  limits  tor  the  various  volumes,  wh^her  the  text  I 

should  be  single  or  double  spaced,  and  the  minimum  acceptable  font/pitch  of  the  text. 

(5)  Evaluation  Criteria  -  Describe  the  evaluation  criteria  and  other  general  considerations  the 
government  will  use  in  evaluating  an  offeror's  proposal  submitted  in  response  to  an  RPP.  The  evaluation 
criteria  listed  in  this  section  of  the  SSP  is  restated  verbatim  in  Section  M,  Evaluation  Factors  tor  Award. 

of  the  RPP.  The  evaluation  criteria  are  intended  to  show  the  scope  of  the  evaluation  to  be  performed  on  I 

proposals,  along  with  identifying  the  relative  order  of  importance  for  each  criterion.  The  three  types  of 
evaluation  criteria  to  be  addressed  in  the  SSP  include;  specific  criteria  that  relate  to  important  project 
characteristics  (referred  to  as  areas  and  items),  cost  (price)  criteria,  and  assessment  criteria  that  relate  to 
an  offeror's  proposal  and  his  ability  to  perform  if  awarded  a  contract. 

(6)  Acquisition  Strategy  -  This  section  of  the  SSP  identifies  the  type  of  contract  proposed,  . 

incentives  conte^ated.  Milestone  demonstrations  intended,  and  any  sp^ial  contract  clauses  to  be  * 

used.  The  information  contained  in  this  part  of  the  SSP  must  be  compatible  with  the  information 

documented  in  the  AP. 
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(7)  Schedule  of  Events  -  Contains  the  schedule  of  significant  source  selection  activities, 
including  sufficient  details  to  enable  the  reviewing  authorities  the  capability  to  assess  the  practicality  of 
the  schedule.  If  the  schedule  contained  in  the  SSP  exceeds  120  days  for  completion  of  source  selection 
activities,  the  project  team  must  include  the  rationale  for  the  extension  beyond  the  1 20-day  schedule. 

c.  As  work  on  the  SSP  is  progressNig,  the  project  team  should  begin  documenting  the  inform^ion 
required  for  the  development  of  the  evaluation  standards.  The  standards  must  be  developed  as  a  starxf- 
alone  document,  and  be  written  specifically  for  each  individual  source  selection.  It  is  recommended  that 
the  evaluation  standards  be  developed  at  the  same  time  as  the  evaluation  criteria,  since  each  of  the 
levels  of  evaluation  criteria  (item,  factor,  subfactor)  contained  in  Sectbn  M  of  the  RFP  must  have  a 
correlating  evaluation  starrdard  to  address  it.  The  project  team  must  write  the  standards  so  that  the 
proposal  evaluator(s)  can  determine  both  strengths  arid  weakrtesses  of  the  proposal(s),  akxtg  with 
determining  the  degree  to  which  the  proposal  exceeds  or  falls  short  of  the  standard.  The  evaluation 
standards  must  be  completed  and  approved  prior  to  beginning  proposal  evaluations. 

d.  As  with  the  majority  of  documentation  associated  with  the  source  selection  process,  the 
information  contained  in  the  SSP  and  the  evaluation  standards  must  be  safeguarded  against 
unauthorized  disclosure.  The  documents  must  be  marked  to  identify  that  they  are  source  selection 
sensitive,  and  safeguarded  as  such.  The  following  legend  should  appear  at  the  top  and  bottom  of  the 
first  page  of  the  documents,  and  at  the  bottom  of  all  subsequent  pages: 

Source  Selection  Information  -  See  FAR  3.104 
Source  Selection  Sensitive 
For  Official  Use  Only 

8.  ENTRANCeEXIT  CRITERIA: 

a.  Entrance:  The  acquisition  strategies  for  a  project  must  be  decided  and  agreed  upon  prior  to  the 
finalization  of  the  SSP  and  evaluation  standards.  This  in  essence  means  the  ASP  must  be  concluded, 
with  an  approved  set  of  minutes  from  the  ASP  forwarded  to  the  project  team. 

b.  Exit:  The  approved  SSP  by  the  SSA  indicates  the  plan  agrees  with  the  decisions  reached  at  the 
ASP,  and  the  approval  is  required  prior  to  release  of  the  final  RFP  to  industry.  The  approval  of  the 
evaluation  standards  indicates  all  levels  of  evaluation  criteria  contained  in  the  SSP  and  RFP  have  a 
correlating  evaluation  standard,  and  the  evaluation  process  may  begin  once  proposals  are  received. 


9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  While  the  RFP  team  is  not  required  by  regulation  to  attend  formal  training  prior  to  the 
development  of  the  SSP  or  evaluation  standards,  training  is  encouraged  to  aid  the  team  in  the  successful 
development  and  completion  of  the  plan  and  standards  (see  Data  Sheet  D63). 

b.  Outputs:  The  out-^uts  from  the  SSP  include  the  evaluation  criteria  that  must  be  included  in 
Section  M  of  the  RFP  (see  Data  Sheet  D64),  along  with  acquisition  strategy  that  is  reflected  in  the  AP 
(see  Data  Sheet  D66).  The  SSP  must  be  approved  before  the  final  RFP  can  be  released  to  industry,  and 
the  approved  evaluation  standards  indicate  proposal  evaluations  may  be  conducted. 

10.  KEY  REFERENCES: 

a.  AFR  70-1 5/AFFARS  Appendix  AA,  27  Apr  88.  Formal  Source  Selection  for  Major  Acquisitions 
and  applicable  supplements  (see  paragraph  5,  above,  for  a  brief  description  of  the  policies/procedures 
covered  in  AFR  70-1 5). 
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b.  AFR  70-30/AFFARS  Appendix  BB,  27  Apr  88,  Streamlined  Source  Selection  Procedures  and 
applicable  supplements  (see  paragraph  5.  above,  tor  a  brief  description  of  the  policies/procedures 
covered  in  AFR  70-30). 

c.  A  Schedule  tor  Acquisition  Planning:  Initial  Acquisition  arxj  Strategy  Development  through 
Source  Selection,  Jan  92,  Prepared  by  ASO/CYX.  This  document  describes  the  tasks  that  a  project 
team  must  acconiplish  from  new  start  review  through  RFP  release,  source  selection,  and  first  Post- 
Award  Conference,  along  with  timelines  for  the  various  tasks/activities  associated  with  major 
acquisitions. 

d.  Source  Selection  Plan  Preparation  Guide,  1  Dec  92,  Prepared  by  ASC/CYX.  Provides 
descriptions  of  the  kinds  of  information  that  must  be  documented  in  aU  SSPs,  along  with  recommending 
general  information  that  may  be  included  in  the  plan  or  inserted  as  attachments  to  the  SSP. 

e.  AFSC  Request  for  Proposal  Process  Guide,  Module  4.9,  Source  Selection  Plan  (SSP),  and 
Module  4.10,  Evaluation  Standards.  Modules  4.9  and  4.10  of  the  RFP  Process  Guide  provide  brief 
descriptions  of  key  FAR  policies  governing  the  SSP  and  evaluation  standards,  along  with  providing 
descriptions  of  the  docurrrents,  applicability  to  other  processes,  arto  the  required  reviews,  approvals,  and 
coordination  associated  with  each  document. 

11.  IMPLEMENTATION  TOOLS:  The  project  team  responsible  for  the  preparation  of  the  SSP  and 
evaluation  standards  should  have  the  above  referenced  documents  available  for  their  use  when 
prepffiing  the  SSP  and  starxlards.  A  copy  of  the  FAR,  or  access  to  FAR  On-Line  must  be  accessible  to 
the  team.  It  is  also  necessary  for  the  project  team  to  have  the  approved  minutes  from  the  ASP,  so  the 
decisions  and  guidance  directed  as  a  resutt  of  the  meeting  can  be  captured  in  the  SSP.  The  project 
team  must  have  available  any  draft  RFPs  that  were  issued  to  industry,  along  with  any  comments 
received  from  industry.  The  comments  received  in  regard  to  the  draft  RFPs  can  be  useful  when 
preparing  the  SSP,  evaluation  standards,  AP,  and  the  final  RFP,  since  the  comments  received  can  alert 
the  project  team  to  problems  in  documentation,  requirements,  artd  possible  flaws  in  acquisition  strategy 
that  need  to  be  dealt  with  prior  to  the  release  of  the  final  RFP. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  ASC/CYX  ’Schedule  for  Acquisition  Planning,”  referenced  in  paragraph  lO.c., 
above,  includes  a  timeline  of  approximately  5  months  tor  the  preparation  and  approval  of  the  SSP  and 
evaluation  standards.  The  time  involved  in  the  preparation  of  the  SSP  and  standards,  however,  is 
subject  to  the  complexity  of  the  project,  the  availability  of  required  documentation  (ASP  minutes,  etc  ), 
the  time  required  to  determine  the  vaiidity  of  comments  received  in  response  to  draft  RFPs  issued,  and 
the  time  required  for  the  actual  review  and  approval  of  the  SSP  and  evaluation  standards. 

b.  CONSTRAINTS:  A  typical  constraint  associated  with  the  preparation  of  the  SSP  is  the 
scheduling  of  individuals  who  are  experienced,  knowledgeable,  and  available  to  serve  as  members  of 
the  source  selection  organization  st  the  required  time.  The  project  team  should  attempt  to  identify  the 
exact  make-up  of  their  desired  source  selection  organization  early  in  the  acquisition  cycle  to  allow 
sufficient  time  to  contact  desired  members  to  determine  their  availability,  and  obtain  their  commitment 
to  serving  on  the  source  selection  team.  Waiting  till  the  last  minute  to  plan  the  organization  of  the 
source  selection  team  may  hinder  the  project  team  from  acquiring  the  most  qualified  personnel  to 
support  the  source  selection. 

c.  RESOURCES:  At  least  one  person  from  each  functional  discipline  should  be  involved  in  the 
preparation  of  the  SSP  and  evaluation  standards.  This  ensures  all  concerns  in  the  specific  functional 
areas  of  the  acquisition  are  recognized,  addressed,  and  dealt  with  prior  to  the  release  of  the  final  RFP, 
and  subsequent  evaluation  process.  A  secured  facility/area  nust  be  available  for  use  by  the  team  when 
preparing  the  SSP  and  standards,  since  these  documents  must  be  protected  against  unauthorized 
disclosure  in  accordance  with  FAR  Subpart  3.104,  Procurement  Integrity. 
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d.  LESSONS  LEARNED:  ASC/CYX  has  documented  numerous  lessons  learned  into  a  text 
entitled,  ASC  Request  for  Proposal  and  Source  Selection  Lessons  Learned.  A  few  of  those  lessons  are 
provided  below  for  the  project  team's  consideration  when  preparing  the  SSP  and  evaluation  standards; 
however,  if  the  project  team  would  like  a  more  comprehensive  data  bank  of  lessons  learned,  contact 
ASC/CYX  for  a  copy  of  the  text. 

(1 )  Early  planning  for  the  source  selection  orgranization,  and  the  associated  responsibilities  of 
team  members  are  essential  for  the  successful  completion  of  the  entire  RFP  and  source  selection 
processes.  It's  important  to  have  the  same  individual(s)  who  wrote  the  Statement  of  Work  (SOW) 
available  to  help  write  the  SSP,  evaluation  criteria,  evaluation  standards,  and  Section  L  of  the  RFP, 
Proposal  Instructions  to  Offerors.  There  must  be  consistency  of  information  throughout  the  documents, 
and  the  individual(s)  responsible  for  writing  the  SOW  have  the  most  knowledge  and  understanding  of  the 
project  requirements;  therefore,  they  should  be  actively  involved  in  the  preparation  of  all  RFP  and  source 
selection-related  documents.  It  is  not  only  important  that  those  responsible  for  writing  the  contractual 
documents  be  responsible  for  writing  the  SSP  and  standards,  but  those  same  people  should  be  on  the 
source  selection  team  as  evaluators,  if  possible. 

(2)  Slippage  of  the  source  selection  schedule  can  occur  if  the  project  team  fails  to  consider  the 
amount  of  clerical  support  required  for  the  RFP  and  source  selection  processes.  While  clerical  personnel 
are  not  considered  permanent  members  of  the  source  selection  team,  it  is  critical  that  the  project  team 
designate  individuals  to  provide  administrative  support  on  a  full-time  basis  during  all  source  selection 
activities.  Part-time  support  should  also  be  available  during  high  volume  workload  periods  to  ensure 
there  is  no  slip  in  schedule. 

(3)  Require  Proposal  "Maps"  and  Cross  References.  One  team  found  that  the  key  to 
understanding  a  complex,  multivolume  proposal  was  to  have  a  map  of  the  proposal  and  an  in-depth 
cross-reference  matrix  of  requirements  to  specific  sections  in  the  proposal.  Standardized  proposal 
structure  (e.g.,  volume  numbering  schemes)  would  also  have  aided  in  the  evaluation.  By  setting  a 
standard  for  numbering  schemes  and  "review  aids"  as  part  of  the  RFP,  the  government  can  ensure  that 
proposal  evaluations  are  thoroughly  performed,  which,  obviously  will  help  in  the  understanding  of  the 
contractor's  proposed  program  and  their  proposed  level  of  risk. 

(4)  It  is  not  a  "sin"  to  project  more  than  1 20  days  for  the  source  selection  in  the  SSP.  Put  in 
what  is  reasonable.  Seme  cases  where  120  days  would  be  unreasonable  would  be  a  large  quantity  of 
proposals  are  expected  to  be  submitted  for  evaluation;  extensive  use  of  Mil-Prime;  or  derrwnstrations  to 
be  conducted  during  the  source  selection.  You  will  be  held  to  your  original  schedule  for  the  duration  of 
the  source  selection;  therefore,  you  should  try  to  project  a  realistic  schedule  in  the  SSP. 

e.  BEST  PRACTICES: 

(1 )  To  avoid  inconsistency  among  acquisition/source  selection  documents,  it's  recommended 
that  the  preparation  of  the  evaluation  standards  occur  simultaneously  with  the  preparation  of  the 
evaluation  criteria,  and  the  proposal  instructions  to  offerors.  The  project  team  may  want  to  ask 
themselves  the  following  questions: 

(a)  Is  this  element  critical  to  my  evaluation? 

(b)  Have  I  told  the  offeror  in  Section  L  of  the  RFP  what  I  want  to  see? 

(c)  Have  I  told  the  offeror  in  Section  M  of  the  RFP  that  this  subject  will  be  evaluated? 

(d)  Have  I  checked  to  be  sure  that  I  haven't  included  the  subject  of  this  element  elsewhere 
in  the  standards? 


(2)  All  key  personnel  involved  in  the  source  selection  should  have  some  prior  experience  with 
source  selection  activities.  This  is  possible  by  allowing  personnel  who  are  new  to  source  selection 
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activities  the  opportunity  to  work  with  experienced  evaluators  before  the  "new”  personnel  actually  hold 
key  positions  such  as  factor  evaluator,  item  captain,  or  panel  chief  on  source  selections. 

(3)  During  the  preparation  of  source  selection  standards,  care  must  be  taken  to  protect  the 
information  from  unauthorized  disclosure.  Not  only  must  ‘hard"  copies  of  documents  be  protected  as 
Source  Selection  Sensitive,  but  information  prepared  on  word  processing  equipment  irxjst  also  be 
safeguarded.  The  project  team  must  ensure  source  selection  standards  prepared  using  word  processors 
are  saved  in  such  a  manner  to  protect  the  information  from  "public'  access,  i.e.,  save  the  standards  on  a 
disk  or  personal  drive  vs  saving  the  information  on  the  public  drive  of  the  word  processor. 

f.  TRAPS:  Failure  on  the  part  of  the  project  team  to  know  what's  contained  in  the  regulations 
governing  source  selection  will  impact  the  completion  of  the  SSP  and  evaluation  standards. 
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1.  ELEMENT:  063.  TBS  1 .3.3.1  (IFC93-3) 

2.  ELEMENT  TITLE:  Establish  and  Train  Request  for  Proposal  (RFP)  Team 

3.  ELEMENT  OWNER(S):  ASClC^X 

4.  ELEMENT  STAKEHOLDER(S):  Program/Project  Manager  (PM),  Functional  Representatives  and 
others  involved  in  preparing  the  RFP 

5.  REQUIREMENT:  There  is  no  regulation  governing  this  item.  The  training  is  provided  as  a  service  by 
the  RFP  Support  Organization  and  is  not  mandatory.  It  is  up  to  the  PM  to  decide  if  the  team  needs 
training  and  what  kind  of  training  is  needed. 

6.  PURPOSE/OBJECTIVES: 

Purpose;  The  purpose  of  this  activity  is  to  establish  the  RFP  team  and  properly  train  the  team 
members  how  to  prepare  an  RFP. 

Objectives;  The  objective  is  for  the  team  members  to  be  trained  as  a  cohesive  team  to  be 
responsible  for  the  preparation,  timeliness  and  quality  of  the  solicitation. 

7.  DESCRIPTION: 

a.  At  this  stage  of  the  program/project,  the  basic  requirement  is  approved,  the  top-level 
acquisition  strategy  has  been  developed,  and  it  is  time  to  start  thinking  about  preparing  the  solicitation. 
Probably  the  most  important  step  at  this  phase  of  the  program/project  is  to  establish  and  train  an  RFP 
team.  Forming  the  RFP  team  is  the  responsibility  of  the  PM  who,  the  majority  of  the  time,  becomes  the 
RFP  team  leader. 

b.  The  composition  of  the  RFP  team  is  a  key  ingredient  to  the  issuance  of  a  quality  product. 
Success  in  the  acquisition  business  requires  teamwork.  Each  program/project  has  unique  aspects  which 
will  drive  the  membership  needs.  No  two  teams  will  have  the  same  makeup.  The  team  must  focus  on 
the  program/project  objectives  and  coordinating  their  efforts.  Each  team  member  must  think  creatively 
and  actively  participate  in  the  development  of  the  RFP.  The  initial  members  of  the  core  team  are  usually 
identified  from  within  the  program/project  office  and  should  be  the  most  experienced,  qualified  available. 
The  following  is  a  list  of  team  members  and  offices  which  should  be  considered; 


‘Program  Manager 
‘Systems  Engineering 
‘Financial  Management 
‘Reliability/Maintainability 
‘Configuration/Data 
‘Contracting  Officer/Buyer 
‘Lead  MAJCOM  Liaison 
Clerical/Administrative  Support 
Contract  Administration  Office 
‘Environmental  Management 
Key  Staff  Liaison 


Deputy  Program  Manager 
Test  and  Evaluation 
‘Logistics/Supportability 
‘Manufacturing/Producibility 
Quality  Assurance 
Civil  Engineering 

Support  Command/Center  Liaison  (e.g.,  ATC,  ALCs) 
Joint  Service  Liaison  (e.g..  Navy,  Army,  etc.) 
Computer  Resources/Software  Engineering 
Other  USAF  activities  (e.g..  Labs,  Test  Centers,  etc.) 


‘Denotes  Typical  Core  Team  Members 


c.  Another  key  ingredient  to  a  successful  RFP  is  team  training.  After  the  team  has  been 
organized  by  the  PM,  it  should  be  trained  with  the  assistance  of  the  RFP  Support  Organization 
(ASC/CYX)  prior  to  starting  work  on  the  request  for  proposal.  All  team  members  should  have  access  to 
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and  be  trained  in  team  building  concepts.  (Actual  team  building  is  not  the  responsibility  of  ASC/CYX. 

The  local  total  quality  office  should  conduct  the  team  building  training.)  A  tightly  bonded  team  has  a  far 
greater  potential  to  provide  a  well  written,  thought-out  RFP  than  a  team  that  is  loosely  organized  as  a 
conglomerate  of  players. 

d.  The  RFP  Support  Organization  (ASC/CYX)  should  be  contacted  when  it  is  time  to  start 
thinking  about  the  RFP  preparation.  They  have  the  expertise  and  resources  available  to  assist  the  PM  in 
establishing  and  training  the  team  and  preparing  the  RFP.  Using  their  AF^  RFP  Process  Guide  (see 
paragraph  10,  Key  References)  will  also  be  valuable  in  establishing  and  training  the  RFP  team.  Some  of 
the  training  modules  available  include;  Model  Contract,  Statement  of  Work,  Data  and  Source  Selection 
Plan. 

8.  ENTRANC&EXrr  CRITERIA: 

a.  Entrance;  The  RFP  team  can  be  formed  and  trained  after  a  requirement,  in  the  form  of  an 
Operational  Requirement  Document  (ORD)  or  Program  Management  Directive  (PMD),  has  been 
approved  and  some  basic  acquisition  strategy  has  been  developed. 

b.  Exit;  This  effort  ends  when  the  RFP  team  has  been  established  and  trained  and  ready  to 
prepare  the  RFP  arxf  support  the  PM  prepare  other  documentation. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs;  The  PM  should  have  an  approved  requirement  (e.g.,  ORD,  PMD,  etc.)  and  basic 
acquisition  strategy  before  developing  and  training  an  RFP  team.  This  strategy  could  come  as  a  result  of 
the  output  from  an  Integrated  Acquisition  Strategy  Process  (lASP)  roundtable  (D58)  or  Acquisition 
Strategy  Panel  (ASP),  depending  on  where  the  program/project  starts  that  process. 

b.  Output;  The  output  of  this  activity  is  an  established,  trained  and  cohesive  team  ready  to 
prepare  the  program/project  RFP.  The  team,  since  they  will  be  thoroughly  knowledgeable  of  the 
program/prc^ect,  can  also  support  the  PM  in  preparir^  other  documentation.  They  can  help  prepare  the 
notice  to  the  Commerce  Business  Daily  (65)  to  help  identify  potential  industry  players  in  the 
program/project.  They  will  also  aid  in  preparing  the  Source  Selection  Plan  and  standards  (D62).  The 
final  output  from  this  team  is  the  RFP  document  (D64). 

10.  KEY  REFERENCES:  AFSC  Request  for  Proposal  Process  Guide,  29  Mar  91 ,  Section  3,  provided 
information  concerning  how  to  establish  and  train  an  RFP  team.  The  Guide  also  includes  information  on 
the  Commerce  Business  Daily  input  and  on  source  selection  plans.  (A  new  AFMC  RFP  guide  is  due  out 
in  Dec  93.) 

1 1 .  IMPLEMENTATION  TOOLS:  ASC/CYX  has  handouts  available  that  they  use  in  their  training 
process.  Examples  include  handouts  on  programmatic  and  scheduling  issues.  They  also  have 
computer-based  RFP  preparation  tools  and  two  automated  RFP  preparation  rooms. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  "Schedule  for  Acquisition  Plannir>g;  Initial  Acquisition  and  Strategy 
Development  through  Source  Selection,"  Jan  92,  prepared  by  ASC/CYX.  indicates  the  average  time 
required  for  establishing  and  training  an  RFP  team  is  approximately  10  days.  (The  10  days  is  sometimes 
spread  out  and  not  done  in  succession.) 

b.  CONSTRAINTS:  A  constraint  is  not  having  team  members  knowledgeable  in  the  acquisition 
process  or  adequate  representation  when  needed,  (i.e.  up  front). 
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c.  RESOURCES:  The  resources  required  will  irx:lude  the  PM  and  all  of  the  functional  and 
support  personnel  needed  to  comprise  the  RFP  team.  Each  program/project  RFP  team  will  probably  be 
different,  based  on  the  requirements  of  the  program/project. 

d.  LESSONS  LEARNED: 

(1 )  It  has  been  shown  repeatedly  that  using  the  ‘new  guy*  as  a  member  of  the  RFP  core 
team  is  not  efficient. 

(2)  In  the  past,  AFMC  personnel  involved  in  developing  RFPs  have  lacked  in-depth 
knowledge  and  training  about  the  RFP  process,  team  formation  and  team  building.  This  team  training 
has  alleviated  this  problem. 

(3)  Continuity  of  RFP  team  members  is  unportant  to  the  successful  operation  of  the 
team.  Ideally,  the  RFP  team  members  should  be  selected  so  that  they  are  available  throughout  the  RFP 
preparation  process  and  also  serve  as  members  of  the  source  selection  team. 

(4)  ASC/CYX  has  a  lessons  learned  handout  available. 

e.  BEST  PRACTICES: 

(1 )  Your  local  RFP  support  organization  is  a  key  contributor  to  the  success  of  your 
solicitation.  Contact  them  early  in  your  RFP  process.  At  ASC,  the  support  organization  is  ASC/CYX, 
DSN  785-7073. 


I 


(2)  Each  team  member  should  read  all  the  routine  program/project  documentation  (i.e., 
PMD,  ORD  or  other  operating  command  document)  and  be  aware  of  the  level  of  funding  and  schedule 
for  the  acquisition.  These  are  important  educational  tools. 

(3)  All  team  members  should  have  received  an  orientation  on  the  AFMC  guiding 
principles  for  total  quality. 

f.  TRAPS:  If  functional  and  support  participants  are  not  involved  from  the  beginning  of  the 
team  forming  and  training  process,  the  overall  effort  can  be  delayed.  Without  an  adequate  number  of 
people  for  the  team  or  not  having  the  right  people  involved,  the  remainder  of  the  team  can  be 
overwhelmed  with  work  and  the  end  product  can  suffer. 
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1.  ELEMENT:  064.  TBS  1 .3.3.3  (IFCd3-3) 

2.  ELEMENT  TITLE:  Prepare  Request  for  Proposal  (RFP) 

3.  ELEMENT  OWNER(S):  ASC/PKC,  ASC/CYX 

4.  ELEMENT  STAKEHOLDER(S):  Program/Projecl  Manag^  (PM).  Program/Project  Contracting 
Office.  ProgranYProject  Team,  functional  Office  Representatives,  and  ASC/CYX. 

5.  REQUIREMENT: 

a.  FAR  15.4,  Solicitations  and  Receipt  of  Proposals  and  Quotations"  Provides  policies  and 
procedures  for  planning  and  preparing  solicilations. 

b.  AFFARS  5315.406,  Preparing  Request  for  Proposals  (RFPs)  and  Request  for  Quotations 
(RFQs)  -  Provides  additional  policies  and  procedures  tor  the  preparation  of  RFP  Sections  A,  H  and  L. 

c.  AFMC  FAR  Sup  531 5.4,  Solicitation  and  Receipt  of  Proposals  and  Quotations  -  Provides 
policies  and  procedures  for  using  and  preparing  solicitations  including  Draft  RFPs. 

d.  ASC  FAR  Sup  5315.4,  Solicitation  and  Receipt  of  Proposals  -  Provides  policies  and 
procedures  for  using  and  preparing  solicitations,  irrcluding  Draft  RFPs. 

e.  FAR  5.202,  Synopsis  of  Proposed  Contracting  Actions  -  Provides  the  policy  and  procedures 
for  synopsizing  RFPs. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  element  is  to  prepare  a  draft  RFP(s)  and  formal  RFP  to 
transmit  the  Government's  requirements  to  Industry. 

b.  Objectives:  The  objective  is  to  prepare  a  quality  solicitation  (RFP)  including  all  the 
Government's  requirements,  including  functional  inputs,  from  which  industry  can  submit  a  responsive 
proposal.  It  is  also  an  objective  to  prepare  a  quality  formal  RFP  by  using  the  draft  RFP  process. 

7.  DESCRIPTION: 

a.  At  this  stage  of  the  project  the  acquisition  strategy  is  being  formed  and  refined.  It  is  time  to 
start  pulling  all  of  the  Government's  requirements  together  to  form  the  solicitation  and  getting  feedback 
from  industry  through  the  draft  RFP  process. 

b.  The  planning  and  development  of  a  new  RFP  begins  with  the  RFP  team  formation  and 
training  process  (D63).  The  RFP  team  consists  of  a  team  leader  (i.e.,  usually  either  the  PM  or  the 
contracting  officer)  and  core  team  (cadre)  made  up  of  representatives  from  functional  and  other  offices 
depending  upon  the  specHic  acquisition,  its  level  of  complexity  and  perceived  risks  involved  in 
accomplishing  the  acquisition.  As  a  group,  the  RFP  team  is  responsible  for  developing  a  timely, 
responsive  and  quality  RFP.  They  ensure  the  RFP  includes  the  strategy  approved  by  the  Acquisition 
Strategy  Panel  (ASP)  and  reflect^  in  the  Acquisition  Plan  (AP).  The  PM  ensures  the  proper  mix  (which 
is  usually  program/project  dependent)  of  functional  experts  is  represented  on  the  team. 

c.  The  whole  RFP  process  is  a  compilation  of  numerous  RFP  activities  and  documents  that, 
when  combined,  result  in  the  government's  requirements  being  communicated  to  industry.  The  activities 
are  documented  in  the  RFP  subprocess  documents  (i.e.,  specifications,  statements  of  work  (SOWs), 
contract  data  requirements  lists  (CDRLs),  security  requirements  (DD254),  source  selection  evaluation 
criteria,  warranty  strategy,  etc.).  The  RFP  is  dejjendent  on  alt  of  these  activities.  RFPs  shall  be 
prepared  using  the  uniform  contract  format  prescribed  in  FAR  1 5.406,  consisting  of  4  parts  and  13 
sections,  where  Parts  I.  Il.and  III  will  eventually  become  the  resulting  contract  (model  contract  in  the 
RFP).  The  specifics  of  what  should  be  in  each  part  are  described  in  the  above  FAR  references  and  the 
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AFSC  RFP  Process  Guide  (see  Implementation  Tools  below).  The  RFP  (including  model  corttract)  is  an 
integrated  document  and  is  complete  when  all  the  team  members'  inputs  have  been  combined  into  one 
complete  document. 

d.  The  FAR  requires  the  use  of  Draft  RFPs  on  most  competitive  acquisitions.  A  Draft  RFP  is  a 
preliminary  version  of  the  formal  RFP.  but  it  is  not  required  for  rKMKompetitive  acquisitions.  H  is  a 
communication  tool  used  early  in  competitive  acquisHiorts  to  promote  a  clearer  understanding  of 
requirements  to  industry  and  obtain  industry  feedback  on  the  planned  acquisition.  Industry  feedback 
from  the  Draft  RFP  enables  the  Government  to  produce  a  nwre  effective,  quality  RFP  and  aids  the 
offerors  in  preparing  better  proposate  in  response  to  the  formal  RFP.  It  should  also  reduce  proposal 
preparation  arid  evaluation  time.  The  Draft  RFP  is  prepared  and  reviewed  in  accordaix^e  wXh  the  above 
requiretnents  then  issued  to  industry.  Industry  reviews  the  document  and  offers  comments  back  to  the 
program/project  team.  Comments  (including  questions,  suggestions,  challenges  to  requirements  and 
general  remarks)  help  eliminate  conflicts,  pare  requiremertts  to  absolute  minimum,  reduce  proposal 
preparation  time,  and  reduce  the  time  required  for  government  evaluation.  The  comments  are  evaluated 
by  the  team  which  incorporates  the  appropriate  ones  into  the  program  planning  and  final  RFP. 

e.  A  finaldormal  RFP  is  not  completed  until  after  the  ASP  (D61 ),  if  one  is  converted,  and 
Roundtable  III  (D67)  of  the  Integrated  Ac^isition  Strategy  Process  (lASP)  is  held.  This  will  ensure  the 
acquisition  strategy  recommended  by  the  ASP  and  any  fi^l  documents  prepared  by  the  Roundtable  III 
participants  are  included  in  the  solicitation.  All  of  the  functional  inputs  are  updated  from  the  Draft  RFP 
as  a  result  of  industry  comments  and  included  in  the  final  RFP.  If  the  program/project  is  an  ACAT I 
program,  DOD  Directive  5000.2  requires  that  the  Milestone  Decision  Authority  (MDA)  review  solicitations 
and  contracts  before  their  release  or  execution  for  the  Demonstration  and  Validation  Phase  or  later 
phases.  The  RFP  could  accompany  the  Acquisition  Plan  and  Acquisition  Strategy  Report  through  their 
coordination/approval  cycle  to  be  approved  by  the  MDA.  The  formal  RFP  can  be  released  to  industry 
only  after  MDA  approval  of  the  RFP  and  approval  of  the  Acquisition  Plan. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  The  RFP  process  begins  after  a  program/project  office  receives  direction  to 
undertake  a  negotiated  acquisition.  An  RFP  team  needs  to  be  established  and  trained  prior  to  preparing 
the  RFP  (D53).  All  RFP  team  members  should  start  planning  what  inputs  wilt  be  incorporated  into  the 
RFP  for  their  area  (see  the  list  of  ir^ts  in  paragraph  9,  below).  (For  example,  issue  a  data  call  for  the 
subsequent  Contract  Data  Requirements  List.) 

b.  Exit:  RFP  preparation  ends  when  the  RFP  completes  its  approval  process  prior  to  its  release 
to  industry. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  Inpirts  to  preparing  the  RFP  include  publishing  the  Commerce  Business  Daily  (CCB) 
notification  and  identifying  potential  sources  (D65),  and  preparing  source  selection  plans  and  stan^rds 
(62).  Also,  every  RFP  team  member  will  have  an  input  to  the  RFP  for  his/her  area.  If  he/she  is  not 
responsible  for  preparing  a  document  that  becomes  a  physical  part  of  the  RFP,  he/she  may  play  an 
important  role  in  the  accomplishment  of  other  numerous  subprocesses  and  subtasks  within  the  RFP 
process.  Every  document  or  activity  in  the  RFP  process  either  provides  input  to  or  receives  input  from 
(or  both)  another  document  or  activity  in  the  process.  The  subprocesses  and  subtasks  include,  but  are 
not  limited  to  the  following: 

-  Acquisition  Strategy  Panel  (ASP) 

-  Acquisition  Plan 

-  Commerce  Business  Daily  (CBD)  Announcements 

-  Source  List 
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-  Specifications  (including  test  and  evaluation  requirements) 

-  Statement  of  Work  (SOW) 

-  Work  Breakdown  Stnx:ture  (WBS) 

-  Source  Selection  Plan 

-  Contract  Data  Requirements  List  (CORL) 

-  Evaluation  Standards 

-  Evaluation  Factors  for  Award  (Section  M) 

-  Proposal  Preparation  Instructions 

-  Model  Contract  (Sections  A  -  J) 

-  Contract  Security  Classification  Specific^ion  (DD254) 

-  Source  Selection  Authority  (SSA)  Delegation 

(All  of  the  atx}ve  sub  processes  and  sub  tasks  are  prepared  by  or  received 
through  the  RFP  team  members  either  as  a  result  of  the  ASP  (D61 )  or  the  Operational  Roundtable 
(D67).  They  are  discussed  individually  in  Part  4  of  the  AFSC  RFP  Process  Guide,  available  from 
ASC/CYX.) 

b.  Outputs:  The  output  is  a  quality  RFP,  including  model  contract,  that  the  Government  can 
release  to  Industry  (069). 

10.  KEY  REFERENCES: 

a.  ASC/CYX's  'A  Schedule  for  Acquisition  Planning:  Initial  Acquisitbn  and  Strategy 
Development  Through  Source  Selection.' 

b.  HO  AFSC  Request  for  Proposal  Process  Guide. 

c.  AFMCR  70-7,  Solicitation  Review  Boards  -  Establishes  criteria  for  Solicitation  Review  Boards 

(SRBs). 

d.  AFR  70-15  (AFFARS  Appendix  AA)  Source  Selection,  contains  policies  and  procedures  on 
conducting  source  selections. 

e.  AFR  70-30  (AFFARS  Appertdix  BB)  Streamlined  Source  Selection,  contains  policies  and 
procedures  (or  corKfucting  streamlin^  source  selections. 

f.  DOD  Instruction  5000.2,  Part  2.C,  Defense  Acquisition  Management  Policies  and  Procedures, 
Change  1 , 26  Feb  93,  contains  guidance  on  solicitations. 

g.  AFMC  Pamphlet  800-7,  Integrated  Acquisition  Strategy  Process,  contains  guidance  on  the 
Roundtable/ASP  process. 

11.  IMPLEMENTATION  TOOLS:  At  ASC.  ASC/CYX  is  the  OPR  for  RFP  preparation  process  (DSN 
785-7613).  They  conduct  training  classes  on  forming  and  establishing  RFP  teams  and  also  conduct 
training  on  how  to  prepare  an  RFP.  ASCA^YX  has  resources,  including  experts,  facilities,  computer 
hardware  and  software,  available  to  facilitate  the  team  to  prepare  an  RFP.  Additional  tools  included  in 
the  AFSC  RFP  Process  Guide  are  the  following: 

-  Generic  RFP  process  flowchart  (for  major  competitive  acquisitions) 

-  Essential  RFP  document  process  interdependencies  flowchart 

-  RFP  critical  sub  process  interdependency  matrix 
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12.  PLANNING  GUIDANCE:. 

a.  DURATION:  This  element  is  Program/Proiect  dependent;  hovvever,  the  ASC/CYX  ‘Schedule 
for  AcquisiHon  Ptanning'  contains  a  generic  time  schedule  for  the  events  leading  up  to  and  issuing  the 
RFP.  That  schedule  shows  approximately  6  months  from  the  time  the  Draft  RFP  is  initiated  urXil  the 
formal  RFP  preparation  is  completed  The  time  allowed  for  the  offeror  to  prepare  its  proposal  is  also 
dependent  on  the  Program/Project.  The  above  ASC/CYX  schedule  also  contains  an  average  time  of 
approximately  60  days  which  should  be  allowed  from  release  of  RFP  to  receipt  of  proposals. 

b.  CONSTRAINTS:  The  source  selection  plan  needs  to  be  approved  prior  to  release  of  the 
competitive  RFP.  The  acquisition  plan  needs  to  be  submitted  and  the  approval  ^hority  needs  to 
authorize  release  of  the  RFP  if  the  acquisition  plan  is  not  yet  approved. 

c.  RESOURCES:  This  item  is  dependent  upon  the  program/project,  but,  as  a  minimum,  there 
should  be  at  least  one  person  from  each  functional  dsciplirre  on  the  program/project  management  team 
preparing  the  RFP.  The  size  of  a  ASC/CYX-trained  RFP  varies  considerably  in  size. 

d.  LESSONS  LEARNED: 

(1)  Schedules  for  preparation  and  release  of  RFPs  should  be  realistic  and  not  ovedy 
optimistic  since  there  are  always  unforeseen  actions  which  come  up  durmg  the  solicitation  process 
phase. 


(2)  Involve  the  contract  reviewer  (ASC/PKCC)  in  the  process  as  an  RFP  team  member 
from  the  beginning  of  the  acquisition.  Issues  are  resolved  earlier  and  c^ality  does  not  need  to  be 
inspected. 


(3)  In  Joint  service  program  acquisitions,  have  a  high  level  management  involvement 
in,  and  commitment  to.  the  RFP  and  source  selection  schedule  early-on  from  all  participating  Services  . 

(4)  Be  prepared  to  write  and  issue  numerous  iterations  of  Draft  RFPs. 

(5)  Seek  and  fully  consider  advice  from  other  organizations  which  have  been  through 
the  process  recently  and  those  who  have  expertise  in  a  certain  area.  (Ex:  ASC/YX  has  expertise  in  the 
pre-Milestone  I  acquisition  process.) 

(6)  Involve  industry  in  the  Draft  RFP  preparation,  not  just  review  of  the  final  product. 

(7)  The  US.  Air  Force  Automated  Lessons  Learned  data  base  has  numerous  lessons 
learned  concerning  various  program/project  factors  which  should  be  reviewed  during  the  RFP 
development. 

e.  BEST  PRACTICES: 

(1 )  It  is  important  that  each  member  of  the  RFP  team  have  a  general  understanding  of 
the  overall  RFP  development  process  including  where  their  assigned  activities  fit.  Without  this 
understaixfing  they  will  likely  end  up  supporting  only  a  small  segment  of  the  overall  process  (their  task) 
rather  than  the  effective  development  of  the  RFP.  A  good  RFP  is  an  integrated  document  and  rx>t  just  a 
bunch  of  pieces  pasted  together  behind  a  cover  page. 

(2)  RFP  team  training  from  ASC/CYX  is  advantageous  in  initiating  the  RFP  process. 

(3)  A  draft  RFP  is  advantageous  to  the  program  and  should  be  used  if  time  permits, 
even  if  it  is  rxM  required.  Through  the  Draft  RFP  process,  earty,  open  and  effective  communication  with 
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industry  resutts  in  greater  understanding  of  requirements,  efficiently  tailored  and  documented 
requirements,  fewer  adversarial  relationships  and  a  sense  of  ownership  in  the  end  product.  The  Draft 
RFP  should  be  a  complete  RFP  and  include,  at  a  minimum,  the  Instructions  to  Offerors  (Section  L), 

Basis  of  Award  and  Evaluation  Criteria  (Section  M).  model  contract  including  contract  line  item  stmcture, 
special  contract  requirements,  contract  data  requirements  list,  statement  of  work  and  specifications. 

Draft  RFPs  are  not  normally  used  in  noncompetitive  acquisitions.  However,  if  industry  feedback  is 
considered  essential  for  sound  planning  of  noncompetitive  acquisitions,  specific  information  may  be 
requested  from  the  potential  contractor  by  an  informal  letter.  This  process  requires  written  approval  and 
must  not  be  used  to  circumvent  the  Justification  and  Approval  (J&A)  process  for  approving 
noncompetitive  acquisitions. 

(4)  The  PM  should  make  a  schedule  early  on  in  the  program/project  which  includes  all 
events  leading  up  to  issuing  an  RFP  and  discuss  it  with  the  RFP  team.  This  will  help  iderMify  all  the  tasks 
and  reviews  to  ensure  the  time  allotted  is  sufficient  to  get  the  job  done  right. 

f.  TRAPS: 

(1)  Be  sure  all  the  functional  representatives  provide  their  respective  RFP  inputs  in  a 
timely  manner  and  that  proper  resources  are  in  place. 

(2)  Be  sure  to  include  enough  time  in  the  schedule  for  issuing  a  Draft  RFP,  possibly  in 
incremental  releases  when  data  becomes  available. 

(3)  Ensure  the  acquisition  is  noncompetitive  (approved  J&A)  prior  to  requesting  Draft 
RFP-type  information  from  a  single  offeror  (See  Best  Practices).  If  you  request  information  from  a  sole 
offeror  prior  to  the  J&A  approval,  you  may  have  given  the  offeror  a  conpetitive  advantage  if  the 
acquisition  is  not  approved  as  noncompetitive. 
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1.  ELEMENT:  065,  TBS  1. 3.3.2  (IFC  93-3) 

2.  ELEMENT  TITLE:  Identify  Potential  Industry  Players 

3.  ELEMENT  OWNER(S):  Product  Center,  Contracting,  and  Small  Business  Offices 

4.  ELEMENT  STAKEHOLDER(S): 

Program/Project  Office 
Program/Project  Manager 
Contracting  Officer 
Small  Business  Office 
Office  of  Public  Affairs 

ft 

5. REQUIREMENT: 

a.  Federal  Acquisition  Regulation  (FAR),  Part  4,  Subpart  4.8,  Contract  Files,  and  applicable 
supplements.  FAR  Part  4  provides  policy  and  procedures  relating  to  the  administrative  aspects  of 
contract  execution.  Subpart  4.8  provides  specific  requirements  for  establishing,  maintaining,  and 
disposing  of  contract  files. 

b.  Federal  Acquisition  Regulation  (FAR),  Part  5.  Publicizing  Contract  Actions,  and  applicable 
supplements.  FAR  Part  5  provides  policies  and  procedures  for  publicizing  contract  opportunities  and 
award  information. 

c.  Small  Business  Act.  15  U.S.C.  637(c)  and  Office  of  Federal  Procurement  Policy  Act,  41 
U.S.C.  416.  The  Small  Business  Act  arxf  the  Office  of  Federal  Procurement  Policy  Act  provide 
requirements  for  government  agencies  to  furnish  for  publication  in  the  Commerce  Business  Daily  (CBD) 
notices  of  proposed  contract  actions. 

6.  PURPOSeOBJECTIVES: 

a.  Purpose;  Identify  potential  industry  players  early  in  the  acquisition  process. 

b.  Objectives; 

(1 )  One  requirement  of  all  government  procurements  is  to  compete  acquisitions 
whenever  possfele,  and  ultimately  select  the  contractor  who  can  best  meet  the  government's 
requirements  at  a  fair  aixl  reasonable  price. 

(2)  The  identification  of  potential  industry  players  early  in  the  acquisition  process 
provides  the  projed  team  the  opportunity  to  determine  whether  the  government's  requirements  can  be 
fulfilled  through  full  and  open  competition,  whether  or  not  a  small  business  or  small  disadvantaged 
business  set-aside  is  appropriate,  or  whether  only  one  source  isavailable  to  fulfill  the  government's 
rec^irement. 

(3)  By  simply  being  aware  of  the  numbers  and  types  of  potential  sources  available  for  an 
acquisition,  the  project  team  will  be  better  prepared  to  move  out  in  the  right  direction  on  a  project,  and 
possibly  avoid  problems  later  in  the  acquisition  cycle. 

7.  DESCRIPTION: 

a.  The  process  for  identifying  potential  contractors  is  two-fold.  Rrst,  sources  can  be  derived 
from  the  personal  knowledge  of  key  acquisition  personnel,  such  as  prograrrVproject  managers  (PM)  or 
contracting  officers,  and  secorxf,  sources  can  be  identified  from  contractor  res|X}nses  to  Commerce 
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Business  Daily  (CBO)  announcennents.  The  CBD  is  the  public  notification  media  to  publicize  (synopsize) 
government  contracting  opportunities,  and  contractors  refer  to  the  CBD  to  identify  projects  for  which  they 
want  to  compete.  The  notice  serves  as  the  government's  toot  for  increasing  possibiitties  for  competttion 
by  enabling  all  contractors  an  opportunity  to  indicate  their  interest  in  competing  for  a  project.  A  majority 
of  potential  players  for  a  project  are  identified  from  responses  to  CBD  notices.  The  notice  placed  in  the 
CBD  is  required  by  the  Federal  Acquisition  Regulation  (FAR),  Part  5,  Publicizing  Contract  Actions,  arxf 
this  regulation  should  be  consulted  early  in  the  planning  phase  of  your  project  to  ensure  compliance  with 
its  requirements. 

b.  As  potential  sources  are  identified,  project  personnel  must  document  such  information  as  the 
name  and  address  of  the  organization,  and  the  size  status  of  the  firm,  if  known.  While  the  PM  has 
primary  responsibility  for  the  initial  development  of  the  source  list,  the  Contracting  Officer  also  plays  a 
key  role  in  its  development.  The  list  may  be  typed  on  plain  bond  paper,  or  AFMC  Form  34,  Source  List, 
may  be  used.  While  the  AFMC  Form  34  is  an  optional  form  that  is  not  widely  used  within  ASC,  H's 
important  to  know  it  is  available  for  use  by  project  personnel.  The  PM  can  b^in  documenting  poterttial 
sources  as  soon  as  sources  become  known  from  early  exploratory  discussions  with  industry. 

Additionally,  project  team  members  may  have  knowledge  of  contractors  performing  work  on  programs  of 
a  similar  nature  to  the  project  in  question,  and  these  contractors  may  be  considered  potential  sources. 
The  list,  however,  is  not  complete  until  all  contractors  have  had  an  opportunity  to  respond  to  a  synopsis 
notice  published  in  the  CBD. 

c.  The  ncrtice  published  in  the  CBD  is  composed  as  a  joint  effort  between  project  team  members. 
The  technical  information  needed  for  the  notice  can  be  compiled  as  soon  as  the  requirements  for  a  new 
project  are  identified.  The  PM  is  responsible  for  having  the  technical  information  compiled,  and  ensuring 
its  accuracy.  Once  the  PM  has  completed  the  technical  requirements  portion  for  the  notice,  the 
information  is  given  to  the  contracting  officer.  The  contracting  officer  is  responsible  for  the  preparation 
of  the  actual  notice,  and  its  subsequent  submittal  to  the  CBD.  There  are  various  categories  of  notices 
published  in  the  CBD,  and  the  project  team  must  determine  which  category  is  appropriate  for  the  project 
The  distinct  characteristics  of  each  project  will  drive  the  exact  type  of  notice  selected  for  publicatbn  in 
the  CBD.  For  guidance  in  determining  which  type  of  notice  is  appropriate  for  the  project,  reference  either 
the  Federal  Acquisition  Regulation  (FAR)  Part  5,  Publicizing  Contract  Actions,  or  the  Request  for 
Proposal  Process  Guide,  Module  4.4,  Commerce  Business  Daily  (CBD)  Notices.  It’s  strongly 
recommended  that  the  project  team  consult  these  documents  early  in  their  planning  phase  because  of 
the  time  frames  which  must  be  met  for  the  publication  of  a  notice  prior  to  release  of  a  request  for 
proposal,  and  because  several  exceptions  do  exist  to  whether  a  notice  is  required. 

d.  Along  with  determining  the  type  of  notice  to  be  used  and  ensuring  the  synopsis  is  prepared  in 
the  proper  format,  the  project  team  must  determine  the  appropriate  Standard  Industrial  Classification 
(SIC)  code,  and  the  correlating  size  standard  for  potential  contractors  (see  Federal  Acquisition 
Regulation  (FAR)  Part  5,  Subpart  5.2,  Synopses  of  Proposed  Contract  Actions,  and  FAR  Part  19, 

Subpart  19.1 ,  Size  Standards).  In  addition  to  including  the  SIC  codes  and  size  standards  in  the  notice, 
the  Contracting  Officer  must  ensure  the  inclusion  of  the  standard  ombudsman  statement  in  hern  1 7  of 
the  notice  (see  Air  Force  Materiel  Command  FAR  Supplement,  Part  15,  Subpart  5315.1 1,  Ombudsman 
Program).  Finally,  the  contracting  officer  must  ensure  the  insertion  of  any  applicable  nunibered  notes  to 
highlight  generic  requirements  of  the  project.  The  purpose  of  the  notes  is  to  l^lp  conserve  space  and 
simplify  the  identification  of  repetitive  notices  in  the  CBD.  The  notes  are  to  be  referenced  at  the  end  of 
the  notice  by  either  inserting  the  appropriate  number  of  the  note,  or  the  notes  can  be  tailored  to  be 
project-specific,  and  be  included  in  the  notice  in  full  text.  An  ex{^anation/description  of  the  numbered 
notes  appears  weekly  in  the  Monday  edition  of  the  CBD,  and  this  edition  of  the  CBD  should  be 
referenced  when  determining  which  notes  may  be  applicable  to  a  specific  project. 

e.  The  contracting  officer  will  ensure  the  synopsis  is  typed  on  AFMC  letterhead,  and  the  original 
plus  four  copies  are  submitted  to  the  Small  Business  Office,  ASC/BC.  The  information  contained  in 
Item  1 7  of  the  notice  should  be  saved  in  ASCII  format  on  a  3-inch  disk  (used  for  electronic  transmission 
purposes),  and  the  disk  should  accompany  the  hard  copies  of  the  notice  submitted  to  the  Small  Business 
Office.  Upon  review  and  coordination  of  the  synopsis  by  the  Small  Business  Office,  ASC/BC  forwards  a 
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copy  of  the  synopsis  to  the  Office  of  Public  Affairs,  Media  Relations  Division,  ASC/PAM,  for  their  review 
and  approval  prior  to  release  of  the  notice  to  the  CBD.  Corxxirrently,  the  Small  Business  Office  forwards 
a  copy  of  the  synopsis  along  with  the  3-inch  disk,  to  the  Contract  Support  Section,  ASC/PKMB.  The 
Small  Business  Office  also  forwards  a  coordination  copy  of  the  synopsis  back  to  the  originating  project 
office,  and  one  copy  is  retained  in  ASC/BC.  The  Office  of  Public  Affairs  reviews  the  notice  to  determine 
the  releasability  of  the  information  to  the  public,  and  notifies  the  Contract  Support  Section  when  that 
determination  is  made.  Upon  notification  from  ASC/PAM,  the  Contract  Support  Section  electronically 
transmits  the  notice,  via  CBD  Express,  for  publication  in  the  CBD. 

f.  Once  the  notice  is  published  in  the  CBD,  interested  contractors  may  submit  documentation  to 
th-?  sponsoring  office  supporting  their  qualifications  to  compete  for  the  proposed  project.  The 
documentation  submitted  in  response  to  the  notice  is  reviewed  by  the  project  team  to  determine  the 
eligibility  status  of  the  contractor.  The  determination  of  a  contractor's  eligibility  to  compete  for  an 
acquisition  involve:  verifying  any  clearances  required  of  the  potential  offeror,  and  ensuring  the 
contractor  is  not  on  the  debarred/suspended  list  (List  of  Parties  Excluded  from  Federal  Procurements  or 
Nonprocurement  Programs).  If  the  project  team  determines  the  contractor  is  eligible  to  receive  a  copy  of 
the  Request  for  Proposal  (RFP),  the  company  is  included  on  the  source  list.  Inclusion  on  the  source  list 
ensures  the  contractor  will  be  mailed  a  copy  nf  the  RFP  when  it  is  ready  for  release  to  industry. 

g.  After  the  project  team  has  identified  all  known  sources,  a  complete  source  list  is  compiled, 
and  the  list  is  forwarded  to  the  the  Small  Business  Office  (ASC/BC)  for  review  and  coordination  The 
review  of  the  source  list  by  ASC/BC  ensures  the  inclusion  of  any  small  or  disadvantaged  business 
concerns  who  may  possess  the  capabilities  to  fulfill  the  government's  requirements  under  the  project. 

The  review  also  aides  in  identifying  potential  small  business  set-asides,  or  possible  subcontracting 
opportunities  for  small  businesses.  As  changes  occur  to  the  source  list,  it  is  important  that  the  project 
team  route  the  revised  list  back  to  the  Small  Business  Office.  This  additional  review  by  ASC/BC 
provides  input  to  whether  the  method  of  procurement  originally  recommended  by  the  project  office 
should  change  (i.e.,  full  and  open  competition  vs  a  small  business  set-aside). 

8.  ENTRANCBEXIT  CRITERIA: 

a.  Entrance:  The  initial  effort  for  identifying  potential  industry  players  for  a  project  can  begin  as 
soon  as  requirements  for  a  new  project  are  identified.  At  thi^;  point,  early  exploratory  discussions  can 
occur  between  the  project  team  and  industry,  and  work  on  an  initial  source  list  can  begin.  Also,  once  the 
requirements  for  the  project  are  identified,  the  PM  can  begin  to  pull  together  the  technical  information 
necessary  to  have  the  proposed  acquisition  synopsized  in  the  CBD. 

b.  Exit:  Receipt  of  contractor  responses  to  the  notice  published  in  the  CBD  identifies  the  majority 
of  potential  players  for  a  project.  Those  respondees  who  are  determined  to  be  qualified  to  compete  for 
an  acquisition  (not  suspended,  debarred,  etc.),  are  included  on  the  source  list  and  will  be  mailed  a  copy 
of  the  RFP. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  technical  accuracy  of  the  information  included  in  the  notice  for  the  CBD  is  key  to 
identifying  prtential  sources  for  a  project  (see  Data  Sheet  D37B).  Contractors  review  the  CBD  to  identity 
projects  for  which  they  may  be  qualified  to  successfully  perform,  and  their  responses  to  a  notice  will  be 
dependent  upon  the  information  contained  therein.  It's  imperative  that  the  technical  information  be 
accurate  so  all  contractors  who  may  be  capable  of  fulfilling  the  government's  requirements  respond  to 
the  notice.  The  project  team  runs  the  risk  of  losing  potential  sources  if  the  technical  requirements 
information  is  not  clear  and  accurate.  On  the  other  hand,  the  project  team  may  also  be  inundated  with 
responses  to  a  CBD  notice  if  the  requirements  information  is  vague  and  unclear. 

b.  Output:  The  complete  source  list,  comprised  of  all  qualified  contractors  known  to  the  project 
team,  and  any  additional  contractors  who  submit  a  request  for  the  RFP,  is  the  key  output  in  the  process 
of  identifying  potential  sources  for  a  project.  This  list  is  used  by  the  project  office  when  the  request  for 
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proposal  is  ready  for  release  to  industry,  since  only  those  contractors  appearing  on  the  list  will  receive  a 
copy  of  the  RFP  (see  Data  Sheet  D69). 

10.  KEY  REFERENCES:  • 

a.  Federal  Acquisition  Regulation  (FAR)  Part  5.  Publicizing  Contract  Actions,  and  applicable 
supplements  (see  paragraph  5,  above,  for  a  brief  description  of  policies  covered  under  FAR  Part  5). 

b.  Federal  Acquisition  Regulation  (FAR)  Part  9,  Contractor  Qualifications,  and  applicable 

supplements.  FAR  Part  9  provides  policies,  standards,  and  procedures  for  determining  a  prospective  • 

contractor's  responsibility,  and  also  provides  policies  governing  the  debarment,  suspension,  and 
ineligibility  of  contractors. 

c.  Federal  Acquisition  Regulation  (FAR)  Part  19.  Small  Business  and  Small  Disadvantaged 
Business  Concerns,  and  applicable  supplements.  FAR  Part  19  implements  the  acquisition-related 

sections  of  the  Small  Business  Act  (1 5  U.S.C.  631 ).  and  provides  specific  policies  for  set-aside  • 

procurements  with  small  or  small  disadvantaged  businesses,  along  with  defining  the  size  standards 
contractors  must  meet  to  be  considered  as  a  small  or  disadvantaged  business  corn^em. 

d.  AFSC  Request  for  Proposal  Process  Guide,  Module  4.4,  Commerce  Business  Daily  (CBD) 

Notices,  and  Module  4.5,  Source  List.  Modules  4.4  and  4.5  of  the  RFP  Process  Guide  provide  a  brief 

description  of  key  FAR  policies  governing  CBD  notices,  and  the  documentation/maintenance  of  the  ^ 

source  list.  * 

11.  IMPLEMENTATION  TOOLS:  Acurrent  copy  of  the  FAR  and  all  applicable  supplements  is  essential 
for  the  project  team  to  ensure  the  requirements  are  met  for  the  publication  of  a  synopsis  in  the  CBD. 

Regulatory  requirements  also  exist  in  FAR  for  the  completion  and  maintenance  of  the  source  list.  If  a 
hard  copy  of  the  FAR  and  all  its  supplements  are  not  available  to  the  project  team,  access  to  FAR-On- 

Line  in  the  Acquisition  Management  System  (AMS)  is  required.  • 

12.  PLANNING  GUIDANCE: 
a.  DURATION: 

(1 )  The  time  involved  in  the  preparation  of  the  notice  for  the  CBD,  and  the  completion  of  the  * 

source  list  will  vary  from  project  to  project.  The  PM  will  require  more  time  for  compiling  the  technical 

information  for  the  notice  when  the  technical  requiremerrts  are  complex.  Once  the  contracting  officer 

has  the  technical  information  for  the  CBD  notice,  he  can  normally  research  the  specifics  required  for  the 

various  categories  of  synopses  and  ensure  the  notice  is  typed  and  forwarded  for  review  by  the  Smalt 

Business  Office  within  2  days  of  receipt  of  the  requirements  information  from  the  PM.  Tum-around  time 

of  a  synopsis  for  review  and  coordination  by  the  Small  Business  Office  is  a  maximum  of  3  days.  The  • 

Office  of  Public  Affairs  receives  the  synopsis  from  ASC/BC,  reviews  the  content  of  the  synopsis,  and 

approves  its  releasability  to  the  public  within  a  maximum  of  2-3  days.  The  tum-around  time  for  a  notice 

in  review  by  ASC/PAM  is  strictly  dependent  on  the  content  of  the  notice.  Many  notices  are  in  and  out  of 

review  in  a  day  or  less  when  the  requirements  for  the  acquisition  are  clear  and  concise,  and  when  no 

additional  coordinations  are  required.  If  a  notice  doesn't  require  additional  reviews  outside  ASC,  the 

Office  of  Public  Affairs  notifies  the  Contract  Support  Section  that  the  notice  may  be  released.  When  the  • 

Contract  Support  Section  receives  the  go-ahead  to  transmit  the  synopsis  to  the  CBD,  the  notice  is 

normally  transmitted  via  the  CBD  Express  within  2  days  of  receipt  of  approval  from  the  Office  of  Public 

Affairs.  Publication  of  the  notice  in  the  CBD  usually  occurs  within  2-3  days  after  receipt. 

(2)  Factors  to  consider  when  developing  the  source  list  should  include  the  response  time  allowed 

for  potential  sources  to  resjsond  to  the  notice  published  in  the  CBD,  review  of  responses  to  the  notice  to  ^ 

determine  eligibility  status  of  the  various  contractors,  clearance  verification  of  potential  sources  when 
applicable,  the  time  needed  to  document  the  sources  on  a  list,  and  the  review  of  the  source  list  by  the 
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Small  Business  Office  (ASC/BC).  The  Small  Business  Office  quotes  a  maximum  of  3  days  to  review  a 
source  list  however,  the  turn-around  time  for  the  review  is  usually  less  than  the  3  days  quoted. 
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b.  CONSTRAINTS:  It  is  important  to  note  that  the  source  list  may  require  updates  throughout 
the  acquisition  process.  Updates  should  occur  as  additional  sources  are  identified,  or  because  the 
eligibility  status  or  size  standards  have  changed  for  previously  identified  sources.  A  contractor's 
eligibility  status  for  receipt  of  a  request  for  proposal  may  change  due  to  debarment,  suspension,  a 
clearance  being  revoked,  or  a  contractor's  clearance  being  downgraded  to  a  level  below  what  is  required 
for  performance  under  the  project.  For  those  specific  reasons,  a  contractor  would  be  removed  from  the 
list  of  contractors  eligible  to  compete  for  the  project.  The  project  team  must  monitor  monthly  updates  to 
the  List  of  Parties  Excluded  from  Federal  Procurements  or  Nonprocurement  Programs  to  ensure  a 
contractor  is  not  placed  on  the  debarred/suspended  list  prior  to  release  of  the  request  for  proposal.  The 
project  team  must  also  ensure  the  Security  Manager  for  the  project  keeps  the  team  inforr^  of  any 
changes  to  the  clearance  levels  of  potential  sources  that  could  impact  the  contractor's  eligibility  to 
compete  for  the  project. 

c.  RESOURCES:  The  resources  involved  in  identifying  potential  industry  players  for  a  project 
involve  personnel  from  various  disciplines.  An  oven/iew  of  their  responsibilities,  and  the  time  involved  in 
performing  their  specific  tasks  is  addressed  below. 

(1)  The  PM  is  responsible  for  compiling  the  requirements  information  contained  in  the 
notice  for  the  CBD.  The  time  involved  in  this  effort  depends  primarily  on  the  level  of  technical 
complexity  of  the  project  in  question.  After  compiling  the  requirements  information,  the  PM  submits  the 
technical  portion  for  the  notice  to  the  Contracting  Officer,  who  in  turn,  conrpletes  the  remainder  of  the 
notice.  The  PM  becomes  involved  in  the  process  again  when  contractor  responses  to  the  notice  are 
submitted  for  review.  The  review  is  simply  a  look  to  see  whether  the  contractor  meets  specific 
requirements  addressed  in  the  notice,  and  is  not  intended  to  be  an  in-depth  evaluation  of  a  contractor's 
ability  to  fulfill  all  aspects  of  the  project.  The  review  basically  verifies  whether  the  contractor's  stated 
qualifications  fall  in  line  with  the  Standard  Industrial  Classification  (SIC)  code  and  the  size  standard  cited 
in  the  CBD  notice.  The  number  of  responses  to  a  notice  is  a  factor  in  the  amount  of  time  required  for 
completing  the  task  of  reviewing  the  contractors'  eligibility  to  compete  for  the  project.  Once  the  review  is 
complete,  the  PM  documents  all  contractors  qualified  to  compete,  and  provides  the  list  to  the  contracting 
officer. 


(2)  The  contracting  officer  is  responsible  for  ensuring  the  notice  is  prepared  for  the  CBD  9 

based  on  the  technical  information  provided  by  the  PM.  Normally,  the  Contracting  Officer  can  research 

the  specifics  required  for  the  various  categories  of  synopses,  and  ensure  the  notice  is  typed  and 

forwarded  for  review  to  the  Small  Business  Office  within  2  days  of  receipt  of  the  requirements 

information  from  the  PM.  After  the  entire  synopsis  process  is  complete,  i.e.,  the  notice  is  sent, 

published,  and  responses  have  been  submitted  and  reviewed  by  the  project  team,  the  complete  source 

list  is  compiled.  If  clearances  are  required  of  contractors  for  performance  under  the  project,  the  • 

Contracting  Officer  must  ensure  the  contractors'  clearances  are  verified  by  the  security  manager  prior  to 

release  of  the  request  for  proposal.  The  Contracting  Officer  also  ensures  the  Small  Business  Office 

reviews  the  source  list  to  identify  any  potential  small  businesses,  or  small  disadvantaged  business 

concerns  that  may  have  been  overlooked  by  the  project  team. 

(3)  The  Small  Business  Office  (ASC/BC)  is  responsible  for  review  of  the  synopsis  notice  ^ 

prior  to  its  submittal  to  the  Office  of  Public  Affairs  (ASC/PAM),  and  the  Contract  Support  Section 

(ASC/PKMB).  The  tum-around  time  of  a  synopsis  for  review  and  coordination  by  the  Small  Business 

Office  is  a  maximum  of  3  days.  The  review  of  the  notice  by  the  Small  Business  Office  helps  identify 

potential  small  business  set-asides,  and  possible  subcontracting  opportunities  for  small  businesses.  The 

review  of  the  source  list  also  takes  a  maximum  of  3  days  by  the  Small  Business  Office.  The  review  is 

required  to  ensure  all  potential  small  businesses  and  small  disadvantaged  business  concerns  are 

included  on  the  source  list.  * 
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(4)  The  Office  of  Public  Affairs  (ASC/PAM)  is  responsible  for  reviewing  the  synopsis 
notice  prior  to  Ks  release  to  the  CBO.  The  review  ensures  the  information  contained  in  the  notice  is 
releasable  to  the  public,  and  that  the  notice  has  been  prepared  in  the  proper  format.  The  review  of  the 
notice  takes  a  maximum  of  2-3  days.  The  Office  of  Public  Affairs  is  also  responsible  for  rxMifyirtg  the 
Contract  Support  Section  (ASC/PKMB)  that  the  notice  can  be  transmitted  to  the  CBO. 

(5)  The  Contract  Support  Section  (ASC/PKMB)  is  responsible  for  the  electronic 
transmission  of  notices  to  the  CBO.  When  the  Contract  Support  Section  receives  the  go-ahead  to  send 
the  synopsis  to  the  Commerce  Business  Daily,  the  notice  is  normally  transmitted  via  the  CBO  Express 
within  2  days  of  receipt  of  approval  from  the  Office  of  Public  Affairs  (ASC/PAM). 

(6)  The  security  manager  assigned  to  the  project  office  is  responsible  for  verifying  the 
clearances  for  all  contractors  identified  on  the  source  list  when  possession  of  a  clearance  is  required  for 
performance  under  a  project.  The  security  manager  can  base  the  clearance  verification  on  current 
information  maintained  in  the  security  files,  or  if  there  is  no  current  clearance  information  available,  the 
security  manager  must  obtain  written  verification  from  the  Defense  Investigative  Service  (DIS),  Central 
Verification  Center.  The  security  manager  can  call,  FAX,  or  write  to  DIS  requesting  the  clearance 
information  for  the  contractors  appearing  on  the  source  list.  It  takes  approximately  5-7  days  to  receive 
written  verification  from  the  DIS  once  the  request  for  clearance  has  b^n  made,  ^sed  on  the  clearance 
information  provided  by  DIS,  the  security  manager  makes  any  necessary  changes  to  the  source  list,  and 
the  list  is  then  returned  to  the  contracting  officer. 

d.  LESSONS  LEARNED:  A  determination  was  made  for  a  project  to  be  synopsized  for  full  and 
open  competition  based  on  moderate  overall  program  risk.  The  Small  Business  Administration, 
however,  recommended  the  project  be  set  aside  for  small  business.  To  resolve  the  issue  a  director-level 
visit  to  several  small  businesses  was  conducted,  and  it  was  revealed  that  at  least  two  small  businesses 
could  adequately  fulfill  the  requirements  of  the  project.  Lesson  leamed-when  attempting  to  determine 
whether  to  recommend  a  project  for  full  and  open  competition  vs  a  small  business  set-aside,  it  is 
imperative  to  have  a  strong,  up-front  technical  analysis  before  contacting  the  ASC  Small  Business  Office 
or  the  Small  Business  Administration.  Insure  that  the  technical  team  can  adequately  document  the 
technical  risk  of  the  project  vs  capabilities  of  small  business  to  meet  minimum  requirements,  and 
establish  technical  screening  criteria  to  be  published  in  the  initial  synopsis  so  that  informed  decisions  can 
be  made.  Do  this  before  recommending  full  and  open  competition  due  to  lack  of  two  or  more  qualified 
small  businesses. 

e.  BEST  PRACTICES: 

(1)  Recommend  bringing  the  Small  Business  Office  (ASC/BC)  into  the  acquisition  process  early 
to  assist  in  the  identification  of  potential  small  businesses,  and  to  help  determine  the  possibility  of  a  small 
business  set-aside.  ASC/BC  involvement  should  begin  prior  to  the  syrxjpsis  notice  being  published  in 
the  CBD,  and  should  continue  until  all  potential  sources  have  been  identified  for  the  project.  The  Small 
Business  Office  plays  a  major  role  in  identifying  those  small  or  disadvantaged  businesses  who  may  be 
qualified  to  com^e  and  p^orm  on  the  proposed  project.  While  the  small  business  identified  may  not 
be  capable  of  performing  as  the  prime  contractor  on  the  project,  the  company  may  be  able  to  perform 
subcontracting  responsibilities  for  the  prime  contractor.  The  project  office  may  save  valuable  time  later 
in  the  acquisition  process  by  not  having  to  make  revisions  to  the  source  list,  or  having  to  change  a 
procurement  from  what  was  thought  to  be  full  and  open  competition  to  a  small  business  set-aside  if 
ASC/BC  is  consulted  early  in  the  acquisition  process.  The  bottom  line  is-use  your  valuable  resources, 
such  as  the  Small  Business  Office,  early  in  the  acquisition  cycle  and  continue  to  draw  on  their  expertise 
throughout  the  process. 

(2)  When  the  PM  is  compiling  the  technical  requirements  information  to  be  included  in  the  CBD 
notice,  it's  in^rtant  to  be  as  specific  as  possible  as  to  what  the  actual  requirements  are  for  the  proposed 
project.  While  the  use  of  notes  at  the  end  of  a  notice  is  recommended  to  shorten  the  length  of  a 
synopsis,  it  is  sometimes  necessary  to  tailor  those  notes  for  specific  project  requirements.  By  tailoring 
the  notes  to  fit  specific  project  requirements,  contractors  will  be  better  equipped  to  identify  projects  that 
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are  within  their  performance  capabilities.  The  contractors'  qualification  statements  will  reflect  their 
understanding  of  the  govemmenf  s  requirements,  arKf  thus  provide  more  accurate  information  back  to 
the  project  office  for  their  use  in  evaluating  the  qualification  status  of  the  contractor.  Also,  if  the 
requirements  of  the  proposed  acquisition  are  determined  to  be  out  of  the  scope  of  the  contractor's 
performance  capabilities,  the  contractor  may  choose  not  to  respond  to  the  synopsis  at  all.  The  fewer  the 
responses,  the  less  time  spent  by  the  project  office  reviewing  and  tracking  the  eligibility  status  of 
potential  sources. 

(3)  It  is  also  recommerKled  that  copies  of  the  source  list  be  made  available  to  potential 
contractors  to  assist  in  identifying  subcontracting  opportunities  or  teaming  arrangements  for  a  project. 
This  is  extremely  beneficial  to  small  businesses  wanting  to  acquire  more  expertise  in  government 
contracting.  A  copy  of  the  source  list  may  be  maintained  in  the  Project  Office  Library,  on  the  ASC 
Electronic  Bulletin  Board,  and/or  a  copy  of  the  list  may  be  included  in  the  rer^est  for  proposal. 

(4)  Whenever  possible,  it  is  recommended  that  the  CBD  Express  be  used  for  the  electronic 
transmission  of  synopses  to  the  CBD.  Notices  transmitted  via  CBD  Express  are  usually  published  within 
2-3  days  of  receipt,  vs  an  average  of  7-10  days  total  transmission/publication  time  when  synopses  are 
sent  through  the  postal  system.  For  transmittal  purposes,  the  Item  1 7  portion  of  the  notice  must  be 
saved  in  ASCII  format  on  a  3-inch  disk.  However,  if  the  information  cannot  be  saved  in  ASCII,  the 
project  office  should  indicate  in  a  note  to  the  Contract  Support  Section,  ASC/PKMB.  the  format  used  in 
saving  the  data  on  the  disk.  The  Contract  Support  Section  can  then  attempt  to  convert  the  information 
into  ASCII  format  so  the  notice  can  be  electronically  transmitted  to  the  CBD.  The  office  of  primary 
responsibility  for  the  CBD  Express  transmission  program  is  ASC/PKMB,  extension  54344. 

(5)  It's  recommended  the  project  team  designate  an  individual  to  receive  training  by  ASC/CYX 
on  the  functions/capabilities  of  the  Preaward  Information  Exchange  System  (PIXS)  Electronic  Bulletin 
Board.  The  individual  would  then  be  responsible  for  entering  information  on  the  PIXS  for  access  by 
other  team  members  and  contractors  connected  to  the  electronic  bulletin  board.  Information  for 
publication  could  include  key  Request  for  Proposal  documentation  such  as  source  lists,  CBD 
announcements,  notice  of  preproposal  conferences,  model  contracts.  Systems  Requirements  Document 
(SRD),  etc.  The  individual  would  be  responsible  for  both  entering  data  on  the  PIXS,  and  deleting 
previously  published  information,  as  applicable.  Project  teams  should  contact  ASC/CYX  for  a  copy  of 
the  PIXS  User's  Manual  for  a  complete  description  of  system  tunctions/capabilities. 

f .  TRAPS: 


(1)  When  the  project  team  is  making  the  determination  for  the  appropriate  Standard  Industrial 
Classification  (SIC)  code,  it  is  imperative  that  the  size  standard  cited  for  potential  contractors  correlates 
with  the  SIC  code  selected.  If  the  two  aren't  in  correlation  with  one  another,  the  Small  Business  Office 
will  return  the  synopsis  to  the  contracting  officer  for  resolution. 

(2)  When  reviewing  the  eligibility  status  of  a  potential  contractor,  it  is  imperative  that  the  project 
team  review  the  List  of  Parties  Excluded  from  Federal  Procurement  or  Nonprocurement  Programs.  If  a 
contractor  appears  on  the  debarred/suspended  list,  they  are  ineligible  to  receive  a  copy  of  the  request  for 
proposal.  The  project  team  must;  therefore,  ensure  the  debarred/suspended  contractor  does  not  appear 
on  the  source  list  of  eligible  contractors  who  will  be  receiving  the  request  for  proposal. 

(3)  Also,  when  there  is  a  possibility  of  classified  information  being  involved  in  a  project,  it  is 
important  that  the  project  office  have  the  clearance  levels  of  potential  sources  verified.  If  a  contractor 
does  not  have  the  appropriate  levels  of  clearance  required  to  perform  work  on  the  project,  or  if  a 
contractor's  clearance  level  is  downgraded  prior  to  the  release  of  the  RFP,  the  contractor  will  be  ineligible 
to  receive  the  request  for  proposal.  The  project  team  must  ensure  the  ineligible  contractor  does  not 
appear  on  the  source  list  with  the  contractors  who  are  eligible  to  receive  the  request  for  proposal. 
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1.  ELEMENT:  D66.  TBS  1  3.2.8  (IFC93-3) 

2.  ELEMENT  TITLE:  Develop  Acquisition  Plan  (AP)  From  Acquisition  Strategy  Report  (ASR) 

3.  ELEMENT  OWI£R<S)  ASC/PK.  ASC/CY 

4.  ELEIKNT  STAKEHOLDERS:  Primary  inputs  to  the  AP  are  by  individuals,  groups,  and 
organizations  that  may  have  a  si^ificant  imp^  on  the  acquisition  plan  including  requirements  and 
using  activities,  legal,  engineering,  co^roller  and  contracting  communtties.  Other  organizations  having 
input  into  the  plan  include  representatives  from  test  and  evaluation,  program  management,  logistics, 
manufacturing,  quality  assurance,  competition  advocate,  environmental,  and  medicaHoccupaiional 
health),  or  other  personnel,  if  appropriate,  considering  the  given  acquisition.  The  Program  Manager  has 
overall  responsbility  tor  the  Acquisition  Plan.  The  C^racting  Officer  with  help  from  other  program 
office  functionals,  prepares  and  maintains  the  Acquisition  Plan. 

5.  REQUIREMENT: 

a.  Federal  Acquisition  Regulation  (FAR)  7.1  and  supplements.  Acquisition  Plans. 

b.  DOD  S000.2M,  Defense  Acquisition  Managemerrt  Documentation  and  Reports,  Part  4, 23  Feb 
91 

6.  PURPOSeOBJECTIVES; 

a.  Purpose;  The  purpose  of  the  AP  is  to  serve  as  a  top  level  planning  document. 

b.  Objective;  Its  objective  is  to  ensure  the  effective  integration  of  various  acquisition  strategy 
events,  documents,  and  activities  to  fulfill  the  user's  needs  in  the  most  effective,  ecorK>mical,  arto  timely 
manner. 

7.  DESCRIPTION;  The  plan  is  used  to  integrate  the  acquisition  strategy  in  a  single  comprehensive, 
coordinated  plan  to  fulfill  the  government's  needs.  It  also  serves  as  a  means  for  documenting  the 
proposed  strategy  and  obtaining  senior  level  approval  of  that  strategy.  Preparation  of  the  AP  must  be  a 
team  approach. 

a.  The  ASR  descrtoes  the  entire  acquisition  program  stnicture  defining  the  relationship 
am(^  acquisition  phases,  decision  milestones,  solicitations,  contract  awards,  systems  engineering, 
design  reviews,  contract  deliverables,  test  and  evaluation  periods,  production  releases,  and  o|)erational 
deployment  objectives.  It  discusses  degree  of  concurrency  and  ph^e  transitions  while  the  AP  is  a  top 
level  fanning  document  focusing  on  the  istant  acquisition  and  its  strategies.  To  minimize  admmistrative 
burden,  common  acquisition  strategy  paragraphs  of  the  ASR  should  be  used  to  help  prepare,  write,  and 
finalize  the  AP  .  The  AP,  irxx>rporating  the  approved  acquisition  strategy,  may  not  be  approved  untN  the 
ASR  has  been  approved  by  the  Milestone  decision  authority.  The  Acquisition  Strategy  Report  and  any 
associated  waivers  will  be  prepared  and  approved  prior  to  formal  solicitation  release.  By  requiring  the 
integration  of  all  the  various  acquisition  facets  into  one  document,  the  Program  Manager  can  use  this  as 
one  of  his  tools  to  successfully  complete  the  acquisition. 

b.  The  contents  of  the  AP  are  prescribed  by  the  FAR  7.1  and  supplements.  Major  topics 

include: 
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-  Background  and  Objectives 
Product  Description 

-  Performance 

-  Cost 

-  Delivery  Periods 
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-  Risks 

-  Milestone  Schedule 

-  Acquisition  Souices/Competition 

-  Contract  type,  special  contract  requirements,  warranties,  etc. 

-  Source  Selection  Procedures 

-  Budgeting  and  Funding 

-  Management  Information  RequiremerSs 

-  Test  and  Evaluation 

-  Logistics 

-  Government  Furnished  Property 

c.  The  approved  AP  reflects  the  authorized  acquisition  approach  and  becomes  an  active 
document  for  the  life  of  the  contract.  The  AP  may  be  necessary  for  individual  corttrads  throughout  the 
life  of  the  program.  H  should  be  updated  if  significant  changes  occur  in  the  acquisition  strategy  or 
program  content. 

d.  APs  as  a  minimum,  must  be  coordinated  through  the  local  competition  advocate,  smaH 
business,  and  legal.  Also,  they  are  normally  coordinated  through  all  functional  offices.  The  cover  sheet 
must  be  signed  by  the  Program  Manager,  Contracting  Officer.  Director  of  Contracts,  and  either  the 
Program  Executive  Officer  (PEO)  or  Designated  Acquisition  Commander,  depending  on  the  nature  and 
size/dollar  amount  of  the  program.  Review/approval  levels  and  procedures  are  described  in  the  Air 
Force  Federal  Acquisition  Regulation  Supplement  ( AFFARS)  7.103. 

e.  For  those  acquisitbns  which  will  use  less  than  lull  and  open  competition,  a  Justification 
and  Approval  (J&A)  must  be  prepared.  Normally,  the  J&A.  and  its  cover  sheet,  the  Justificatbn  Review 
Document  (JRD),  are  prepared  along  with  the  A^isition  Plan. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  AP  preparation  usually  takes  place  early  during  tomnulation  of  the  acquisition 
strategy  and  preparation  for  the  ASP. 

b.  Exit  Finalization  of  the  AP  occurs  immediately  after  the  Acquisition  Strategy  Panel  (ASP) 
and  must  be  done  in  time  to  allow  for  the  required  approvals. 

9.  KEY  INPUTS  AND  OUTPUTS; 

a.  Inputs; 

(1)  Program  Management  Directive. 

(2)  Operational  Requirements  Document, 

(3)  A^isition  Strategy  Panel  Minutes, 

(4)  Source  Selection  Authority  Delegation, 

(5)  Sources  Sought  Results  from  Commerce  Business  Daily  synopsis, 

(6)  Acquisition  Strategy  Report. 

b.  Outputs: 

(1)  Acquisition  Plan, 

(2)  Cover  Sheet, 

(3)  Coordination  Sheet. 

10.  KEY  REFERENCES: 

a.  Federal  Acquisition  Regulation  7.1 .  provides  applicatioivcontent  of  Acquisition  Plans. 
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b.  Defense  Federal  Acquisition  Regulation  Supptemem  207.3,  establishes  when  acquisition 
plans  are  required. 

c.  Air  Force  M^erial  Command  Federal  Acquisition  Regulation  Supplement/ 

AFFARS  7.103,  establishes  required  dollar  thresholds  and  programmatic  approvais/coordinations  oi  AP. 

d.  Air  Force  Acquisition  Model  (AFAM)  dated  3  Jul  92. 

e.  A  Schedule  For  Acquisition  Planning:  Initial  Acquisition  and  Strategy  Development  Through 
Source  Selection  (ASC/CYX)  dated  Jan  93 

11.  IMPLEMENTATION  TOOLS:  The  regulations  and  guidance  listed  above. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  AP  can  be  prepared  in  30  days  or  less.  deperxJing  on  complexity  of  the 
acquisition. 

b.  CONSTRAINTS:  The  AP,  incorporating  the  approved  acquisition  strategy,  may  not  be 
approved  until  the  ASR  has  been  approved  by  the  Milestone  decision  authority. 

c.  RESOURCES:  Preparation  of  the  AP  must  be  a  team  approach  and  include  input  from  all 
functional  areas  and  the  program  manager  to  develop  and  finalize  the  AP. 

d.  LESSONS  LEARNED:  Write  Clear  and  concise  APs.  Even  though  the  plan  consists  of 
input  from  many  functional  specialities,  it  is  ultimately  the  responsibility  of  the  Program  Manager  and  the 
C^racting  Offcer  to  ensure  that  when  read  from  cover  to  cover,  it  concisely  and  consistently  describes 
what  will  be  acquired  and  how  the  acquisition  will  be  accomplish^. 

e.  BEST  PRACTICES: 

(1)  Work  hard  to  clea^  describe  the  scope  of  the  intended  acquisition.  TheAP 
language  may  later  be  used  to  determine  whether  proposed  contract  changes  are  within  the  scope  of  the 
2KX|uisition. 

(2)  Prior  to  final  preparation  of  the  AP  all  parties  involved  in  the  ASP  that  provided 
recommended  changes,  should  be  invited  to  an  additional  discussion/agreement  session  addressing 
input  for  clarification/justification  so  the  final  document  represents  the  coordinated  position  of  all 
involved. 

(3)  The  Acquisition  Plan  should  be  drafted  prior  to  the  ASP.  This  draft  plan  then  forms 
the  outline  for  the  briefing. 

f.  TRAPS:  Be  sure  the  AP  either  incorporates  the  acquisition  decisions  made  at  the  ASP  or 
explains  major  differences  from  those  made  at  the  ASP. 
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1.  ELEMENT:  D67.  TBS  1 .3.2.9  (IFC  93-3) 

2.  ELEMENT  TITLE:  Conduct  Operational  Roundtable 

3.  ELEMENT  OWNER:  HQAFMC/XRM 

4.  ELEMENT  STAKEHOLDER(S): 

0  PrograrrVProject  Manager 

o  Program  Executive  Officer  (PEO)  or  Designated  Acquisition  Commander  (DAC) 

0  Integrated  Acquisition  Strategy  Process  (lASP)  Secretariat,  ASC/CYX 
0  HQ  AFMC/XRMP 
o  Functiortal  Home  Offices 

5.  REQUIREMENT:  AFMC  Pamphlet  800-7,  20  Nov  92,  Part  II 

6.  PURPOSE/OBJECTIVE:  The  Operational  Roundtable  e  a  working  group  or  a  series  of  working 
groups  designed  to  develop  and  ’harmonize  ’  (read  as  coordinate)  the  detailed  functional  plans  and 
Milestone  directed  documentation.  (Functional  plans  include  those  documents  not  reviewed  directly  by 
the  Milestone  Decision  Authority  (MDA),  but  which  might  be  used  as  supporting  material.  They  also 
include  those  documents  used  by  the  Program/Project  office  to  actually  execute  the  project.) 

7.  DESCRIPTION:  This  is  the ’write  the  plans’ portion  of  the  lASP.  (This  is  probably  better  titled 
’finalize  the  plans*  portion  of  the  lASP.  The  majority  of  the  plans  will  come  to  the  Op^ational 
Roundtable  in  draft  form.)  The  meeting  is  chaired  the  Program/Project  office  .  Participants  are 
selected  by  the  Tactical  Roundtable  and  will  include  Program/Project  office  functional  experts  as  well  as 
functbnal  experts  with  recent  experience  in  drafting  functional  plans.  (An  example  might  be  to  get  some 
furKtiorral  experts  from  the  LANTIRN  FMS  project  for  the  Saudi  F-1 5  sale  to  assist  with  the 
development  of  the  required  documentation  for  a  potential  JDAM  sale  to  Korea.) 

Another  key  part  of  the  Operational  Roundtable  is  to  ensure  everyone  is  ’singing  from  the  same  sheet  of 
music.’  The  words  in  AFMC  pamphlet  800-7  are  'facilitate  completeness  and  hamriony  of  the 
documentation  and  its  timely  approval.*  This  ’harmony’  refers  not  only  to  an  agreement  between  the 
participants  as  to  the  content  of  each  of  the  documents  but  an  agreement  in  the  content  between  each  of 
the  documents.  This  step  alone  makes  the  Operational  Roundtable  a  very  worthwhile  activity.  If  the 
Program/Project  team  elects  not  to  go  through  an  Operational  Roundtable,  they  should  at  least  develop 
some  kind  of  process  to  ensure  that  all  the  functional  plans  and  required  Milestone  documentation  are 
consistent  with  one  another. 

The  Operational  Rourxltable  participants  are  not  expected  to  create  the  documents  from  scratch. 
Preliminary,  draft,  or  partially  developed  functional  ^ans  and  required  Milestone  documents  should  be 
brought  to  the  table.  A  list  of  these  plans  and  documents  should  include  but  is  not  limited  to: 

1 )  Acquisition  Program  Baseline  (APB) 

2)  Test  and  Evaluation  Master  Plan  (TEMP) 

3)  Integrated  Logistics  Support  Plan  (ILSP) 

4)  Computer  Resources  Life  Cycle  Management  Plan  (CRLCMP) 

5)  Integrated  Weapons  System  Master  Plan  (IWSP) 

6)  Security  Master  Plan  (SMP) 

7)  Systems  Engineering  Master  Schedule  (SEMS) 

8)  Systems  Engineering  Management  Plan  (SEMP) 

9)  Program  Protection  Plan  (PPP) 

10)  Risk  Managernent  Plan  (RMP) 

11)  Nuclear  Certification  Plan  (NCP)  (if  necessary) 

12)  Cost  Analysis  Requirements  Do^ment  (CARD) 
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13)  Certain  nonrrtajor  programs  may  use  a  Program  Management  Plan  (PMP)  to  replace  all  the 
functional  plans,  but  the  PMP  is  generally  not  used  on  major  programs  anymore. 

Along  with  this  list  of  plans  and  documents  to  be  “harmonized*  by  the  Ofi^atbnal  Roundtable 
members,  the  group  will  need  the  documents  which  have  already  been  “approved.’  Such  as  : 

1)  Acquisition  Plan  (AP) 

2)  Integrated  Program  Summary  (IPS)(and  its  annexes) 

3)  Operational  Requirements  Dement  (ORD) 

4)  Mission  Needs  Statement  (MNS) 

5)  Milestone  0  AcquisHion  Decision  MemorarKfum  (ADM) 

6)  Program  Management  Directive  (PMD). 

7)  Cost  and  Operational  Effectiveness  Analysis  Report  (COEA) 

8)  Meeting  minutes  from; 

-  ASP  and  previous  Roundtables 

-  Summit  meetings  (if  they  have  been  held) 

8.  ENTRANCE/EXIT  CRITERIA; 

a)  Entrance.crrteria  to  initiate  an  Operational  RourKitable  are  the  completion  of  the  Acquisition 
Strategy  Panel  (ASP)  and  the  availability  of  the  attendees.  A  time  for  this  Roundtable  should  be  set  at 
the  Tactical  Roundtable. 

b)  Exit  criteria  for  this  Roundtable  includes  the  lofty  goal  of  producing  “a  coherent,  integrated 
program  strategy  supported  by  a  consistent,  harmonious  set  of  approved  implementation 
documents.. .and  the  program  should  be  ready  for  implementation.*  Boiled  down,  the  Operational 
Roundtable  needs  to  be  able  to  answer  “yes*  to  the  following  questions; 

1)  Have  we  thoroughly  examined  the  minimum  set  of  alternative  concepts  as  directed 

in  the  ADM? 

2)  Does  the  COEA  report  address  the  deficiency  as  stated  in  the  MNS? 

3)  Are  the  findings  in  the  COEA  report  reflected  in  the  ORD? 

4)  Does  the  COEA  report  and  the  ORD  use  the  same  System  Threat  Assessment? 

5)  Is  the  selected  acquisition  strategy  consistent  with  the  COEA  findings  and  the  ORD? 

6)  Are  the  Acquisition  Plan  (AP)and  the  Acquisition  Strategy  Report  (ASR)  consistent 
with  one  another? 

7)  Is  the  Acquisition  Program  Baseline  (APB)  consistent  with  the  COEA,  ORD,  and  the 

ASR? 

8)  Are  we  (the  User)  willing  to  cancel  the  program  if  we  breach  any  of  the  thresholds 
stated  in  the  baseline? 

9)  Is  the  TEMP  consistent  with  the  COEA,  ORD,  ASR,  and  APB? 

10)  Have  long  lead  Test  and  Evaluation  resources  been  identified  and  is  there  a  plan  to 
put  them  in  place? 

11)  Are  the  Measures  of  Effectiveness  (MOE),  Measures  of  Outcome  (MOO),  arxf 
Measures  of  Performance  (MOP)  all  addressed  in  the  TEMP?  Are  they  testable  (or  at  least 
“simulatable*)? 

12)  Are  the  MOE  consistent  with  those  in  the  COEA? 

13)  Are  the  assumptions  in  the  Cost  Analysis  Requirements  Document  (CARD)  same 
set  of  assumptions  as  used  in  the  COEA  and  the  program/project  office  cost  estimates? 

14)  Does  the  SEMS  or  SEMP  mesh  with  the  APB  and  the  selected  acquisition  strategy? 

15)  Does  the  SEMP  mesh  with  the  ILSP  and  the  selected  acquisition  strategy? 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs  include  the  documents  listed  in  the  description  portion  of  this  data  sheet  (in  various 
stages  of  preparation).  Particular  tasks  that  should  have  been  completed  in  order  to  conduct  a  successful 
Operational  Roundtable  include; 
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1 )  Acquisition  Strategy  Panel  (ASP)  completion  in  order  to  ensure  that  the  core 
documentation  arid  basic  strategy  is  consistent  with  the  top-down  direction  provided  in  the  Strategic 
Roundtable.  (D57) 

2)  Most  currerrt  version  of  the  System  Threat  Assessment  (STAR  or  ST A) 

to  make  sure  the  project  documentation  is  consistent  with  what  DIA  is  going  to  be  providing  the 
Milestone  Decision  Authority.  (D56). 

3)  You  also  need  to  have  back  (for  ACAT I  or  p^ential  ACAT I  programs)  the 
comments  back  from  the  USD(A)  review  of  the  project's  Acquisition  Strategy  Report  (ASR)  and 
Acquisition  Plan  (Acq  Plan).  (B17). 

b.  Output  is  a  consistent  plan  for  executing  the  next  program  phase  which  has  been  recorded  in 
a  set  of  functional  plans  and  documents  which  are  consistent  with  one  another.  (D68). 

10.  KEY  REFERENCES:  Currently  the  only  references  which  discuss  the  methods  for  accomplishing  an 
Operational  Roundtable  are; 

0  AFMC  Pamphlet  800-7  dated  20  November  1992),  Intanrated  Acquisition  Strategy  Process  (This 
pamphlet  also  lists  a  number  of  references,  but  these  references  are  more  to  be  used  by  the  rouncttable 
participants  in  preparing  the  documentation  and  plans  rather  than  on  how  or  what  the  roundtable  process 
is  all  about.) 

0  ASC/CC  Letter  dated  22  September  1992,  Interim  Acotii-sition  Strategy  PanellASP)  Policv  (This 
policy  letter  gives  direction  for  those  programs  might  be  trapped  between  the  ASP  process  and  the 
institutionalizing  of  the  lASP.) 

11.  IMPLEMENTATION  TOOLS:  None  identified.  (The  lASP  and  Roundtable  concept  is  a  relatively 
recent  development.  No  program/project  has  to  date  accomplished  an  Operational  Roundtable.) 

12.  PLANNING  GUIDANCE: 

9  A.  DURATION: 

-  For  an  ACAT  I  effort,  the  original  concept  for  the  Operational  Roundtable  called  for  6- 
8  weeks.  This  can  be  done  through  a  series  of  meetings  for  irrtegration  with  individual  efforts  in 
between  times  or  by  setting  up  an  offsite  type  of  environmerrt. 

-  ACATs  ll-IV  durations  would  depend  on  how  many  functional  plans  and  documents  are 
required.  If  the  project  opts  to  use  a  single  Program  Management  Plan  (PMP),  this  process  could 
pe^aps  be  cut  in  half. 

For  any  type  of  program,  the  duration  is  going  to  be  determined  by  how  complete  and 
consistent  the  plans  and  documentation  are  when  submitted  to  the  Operational  Roundtable.  If  the 
Program/Project  office  did  an  exceptional  job  in  preparing  the  ’’preliminary’  documents  ,  then  the  work 
of  the  Roundtable  group  will  be  relatively  straightforward  and  could  probably  be  accomplished  in  a 
single  week. 

-  Again,  an  Operational  Roundtable  has  yet  to  be  accomplished  so  there  is  no  real  world 

experience. 

B.  CONSTRAINTS; 

-  These  will  vary  greatly  depending  on  the  program/project,  but  should  be  provided  by 
the  ASP  and  the  members  of  the  Tactical  Roundtable.  It  is  the  responsibility  of  the  prograni/projecf 
manager  to  provide  a  list  of  all  these  constraints  to  the  Operational  Roundtable  team.  The  primary 
constraint  is  scheduling  the  right  people  to  make  them  available  for  the  6-8  weeks  needed  to  complete 
the  activity.  It  is  very  important  to  have  all  the  same  individuals  work  this  activity  from  start  to  finish. 

C.  RESOURCES: 

-  The  membership  on  the  Operational  Rouixftable  is  determined  by  the  participants  of 
the  Tactical  Roundtable. 

-  Leader  to  be  provided  by  the  Program/Project  office. 

-  Most  of  the  members  will  consist  of  the  senior  functional  experts  in  the 
Program/project  office. 
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-  Most  ol  the  members  will  consist  of  the  senior  functional  experts  in  the 
Prof^am/project  office. 

-  Functional  experts  with  recent  experience  in  developing  the  functional  plans  on  other 


projects. 

-  Other,  more  specific  resources,  will  be  listed  as  they  are  discovered  through 
experience  with  the  process. 


0.  LESSONS  LEARNED: 

-  Do  not  rush  into  this  particular  Roundtable.  During  this  phase  of  the  lASP,  aN  the  gory 
detaite  that  the  team  is  going  to  be  forced  to  execute  over  the  next  phase  (if  not  the  entire  life)  of  the 
project  are  developed.  Let  the  ‘experts'  help  to  ‘harmonize*  the  documentation  only  after  the  team  is 
satisfied  that  it  can  live  with  what  it  has  provided  in  the  preliminary  documents.  Remember,  the  role  of 
the  Operational  Roundtable  is  to  ensure  the  consistency  of  the  documentation.. .their  task  is  not  do  an 
executabilHy  study.  If  the  Operational  Roundtable  is  provided  a  draft  document  that  describes  activities 
the  project  cannot  possibly  hope  to  accomplish,  their  job  would  be  to  ensure  that  this  unexecutable 
activity  is  reflected  (as  appropriate)  in  all  the  related  document^ion.  What  is  being  said  here  is  that  this 
group's  role  is  not  to  say  that  what  is  described  to  them  is  not  executable--but  rather,  their  task  is  to 
make  sure  that  all  the  documentation  reflects  a  sense  of  unity.  The  point  to  take  away  is  that  if  this 
group  is  provided  good  raw  materials,  they  should  provide  a  good  final  product  whose  parts  are 
cor^istent  with  one  another. 

E.  BEST  PRACTICES: 

-  When  the  Program/Project  office  begins  to  put  together  the  Milestone  documentation 
and  functional  plans,  ensure  each  draft  document  is  reviewed  for  consistency  with  the  other  documents 
and  with  the  guidance  you  have  already  been  provided.  (It  sounds  almost  insultingly  corrwnon  sensical, 
but  it  hasnl  been  done  on  a  regular  basis.)  Allow  time  for  ‘In-House  Harmonization.’  It's  belter  to 
develop  a  phased  in  approach  that  calls  for  the  documents  to  be  completed  in  sequence  to  allow  time  for 
the  authors  to  review  the  documents  for  consistency  which  have  already  been  completed. 
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F.  TRAPS: 

-  Do  not  grab  the  latest  copy  of  a  particular  functional  plan  and  use  it  as  the  sole  source 
for  creating  the  same  type  of  plan  for  your  project,  (i.e.  If  writing  a  Test  and  Evaluation  Master  Plan 
(TEMP)  for  the  AIM  -9X,  don't  take  the  latest  version  of  the  JDAM I  TEMP  and  do  some  kind  of  word 

search  that  changes  all  references  to  JDAM  I  to  AIM-9X.)  B 

-  Top  down  directed  schedules  may  not  allow  adequate  time  to  accomplish  all  the 
required  work  in  a  quality  manner.  Be  sure  you  notify  senior  leadership  when  such  problems  arise. 
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At 

4.  ELEMENT  STAKEHOLOER(S):  HQ  USAF/XOR  ,  OSD/PA&E.  SAF/AQX.  SAE.  Service 
Secretary,  Of)erating  Command,  Implementing  Command,  Aeronautical  Systems  Centers  (ASC) 

Functional  Organizations,  ASC/YX,  ASC/CYX,  HQ  AFMC/XRMP 

5.  REQUIREMENT 

a.  DoD  Directive  5000.1 ,  Defense  Acquisition,  23  Feb  91 ,  Part  1 .  This  regulation 
contains  information  concerning  acquisition  strategies  and  program  plans. 

b.  DoD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
1991 ,  Parts  2  and  5.  This  regulation  contains  information  on  the  Milestone  (MS)  Review 
Documentation  Concept,  Risk  Management,  and  Acquisition  Category  (ACAT)  Milestone  (MS) 

Documentation  Requirements. 

c.  OoD  5000.2-M,  Defense  Acquisition  Management  and  Documentation  Reports,  23  Feb  91 . 

This  manual  contains  procedures  and  formats  to  be  used  to  prepare  MS  documentation. 

6.  PURPOSE/OBJECTIVE: 

a.  Purpose:  Serves  as  the  primary  means  for  the  project  team  to  provide  the  Milestone 
Decision  Authority  (MDA)  with  the  information  needed  to  make  an  MS  decision. 

i 

b.  Objective:  Ensure  the  documents  are  finalized  in  preparation  for  the  MS  I  documentation 
review  (B22). 

7.  DESCRIPTION: 

a.  The  draft  documents  and  plans  (D60)  are  updated  and  completed  by  the  project  office  with 
selected  functional  experts  who  have  current  applicable  experience.  The  update  may  incorporate  the 
Operational  Roundtable  (D67)  recommendations.  The  documentation  is  limited  to  that  required  to 
support  the  purpose  of  the  MS  review  and  to  that  required  by  statute.  The  scope  and  formality  of  the 
documentation  required  to  support  the  purpose  of  the  review  depends  on  the  project  Acquisition 
Category  (ACAT). 

b.  Documentation  developed  and  submitted  in  support  of  an  MS  review  can  be  grouped 

into  three  general  categories  -  requirements  documents,  the  integrated  Program  Summary  (IPS)  with 
annexes,  and  stand-alone  documents.  The  requirements  documents  provide  information  tor 
decision  makers  on  projected  mission  needs.  The  IPS  with  annexes  and  the  stand-alone  documents 
provide  intormation  neetoed  to  develop  the  Integrated  Program  Assessment  (IPA)  (A21)  so  that  the  MDA 
may  make  an  MS  decision. 

c.  DoD  Manual  5000.2M  includes  formats  for  the  major  items  of  documentation.  These  formats 
are  intended  to  be  used  for  the  documentation  and  rejTorting  requirements  of  ACAT  I  programs  and  for 
ACAT  II,  III,  and  IV  programs  as  required  by  statute.  At  the  discretion  of  the  MDA,  these  same  formats 
MAY  be  used  for  non-statutory  ACAT  II,  III,  and  IV  program  requirements,  tailored  to  the  specifics  of  the 
program. 

d.  The  Operating  MAJCOM/CC  uses  the  results  of  the  Concept  Exploration  (CE)  Studies  and 
the  Cost  arto  Operations!  Effectiveness  Analysis  (COEA)  to  justify  and  select  a  preferred  alternative. 
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Working  with  the  acquisition  community,  a  briefing  is  prepared  to  gain  CSAF  and  MDA  concept 
demonstration  approval.  .After  establishing  an  Air  Force  position,  the  user,  implementer.  and  the  PEO 
(or  Service  Acquisition  Executive  (SAE)  for  smaller  programs)  prepare  the  do^ments  required  for  the 
MS  I  review  (Concept  Demonstration  Ajsproval).  The  PMD  (BIO)  should  have  assigned  tasking  for  the 
applicable  documents.  The  number  and  types  of  documents  arKi  amount  of  detail  will  vary  by  the  ACAT 
level.  A  Defense  Acquisition  Board  (DAB)  program  requires  approximately  ten  major  documents. 
SAF/AQ  approves  acqusition  program  do^ments  before  sending  them  to  the  Joint  Requirements 
Oversight  Council  (JROC)  and  the  DAB.  The  HQ  USAF-approved  Operational  Requirements  Document 
(ORD)  is  the  basis  for  all  follow-on  program  documentation 


Table  E-3  Documents  required  for  Ui^stone  I  Decision  Review 
(A  narrative  explanation  of  MS  I  Documents  may  be  found  in  D60) 


MS  1  DOCUMENTS  (format  in  DoD  5000  2-M) 

ACAT  LEVEL 

J_ 

_ u _ 

_1U _ 

JV 

Operational  Requirements  Document  (ORD) 

X 

X 

X 

X 

System  Threat  Assessment  Report  (STAR) 

X 

System  Threat  Assessment  (ST A) 

X 

X 

X 

Integrated  Program  Summary  (IPS) 

X 

X 

X 

X 

Program  Life  Cycle  Cost  Estimate 

X 

X 

X 

X 

Acquisition  Program  Baseline 

X 

X 

X 

X 

Test  &  Evaluation  Master  Plan  (TEMP) 

X 

X 

X 

X 

Component  Cost  Analysis  (CCA) 

X 

X 

X 

X 

Cost  &  Operational  Effectiveness  Analysis  (COEA) 

X 

X 

X 

X 

Defense  Intelligence  Agency  (DIA)  Report 

0 

Intelligence  Report 

0 

0 

Joint  Requirements  Oversight  Council  (JROC)  Report 

0 

Integrated  Program  Assessment  (IPA) 

0 

0 

0 

0 

Independent  Cost  Estimate  (ICE)  Report 

0 

Acquisition  Decision  Memorandum  (ADM) 

0 

0 

0 

0 

X:  Prepared  by  Military  Dept/PM 

0: 

Prepared  by  OSD  Staff 

Table  1  •  Documents  required  for  Milestone  I  Decision  Review 
( A  narrative  explanation  of  MS  I  Documents  may  be  found  in  D60) 


e.  Integrated  Program  Summanr  (I PST  The  IPS  will  be  addressed  more  thoroughly  here,  since 
it  is  the  primary  decision  document  used  to  facilitate  top-level  acquisition  MS  decision  making  and  is  not 
contained  in  other  data  sheets  The  purpose  of  the  IPS  is  to  provide  a  succinct  integrated  picture  of  the 
program  status  for  use  by  the  MDA,  supporting,  and  review  forums.  It  highlights  the  status  of  critical 
areas  and  plans  for  future  acquisition.  At  MS  I,  the  IPS  shall  summarize  the  results  of  Phase  0,  Concept 
Exploration  and  Definition.  When  writing  the  IPS  the  project  team  needs  to  identify  and  provide  the 
following  information: 

(a)  The  most  promising  concept(s)  to  be  carried  into  Phase  I.  Demonstration  and 
Validation,  for  demonstration  and  further  development,  and  the  reasons  for  elimination  of  alternative 
concepts. 

(b)  The  risk  reduction  efforts  to  be  accomplished  during  Phase  I. 

(c)  The  trade-off  decisions  to  be  made  for  MS  I,  and  recommended  to  be  made  for  MS 

II,  by  the  MDA. 

(d)  The  design  alternatives  and  trade-offs  to  be  evaluated  during  Phase  I. 

(e)  A  summary  of  the  program  life-cycle  cost  estimate,  independent  cost  estimate, 
affordability  assessment  and  proposed  concept  baseline. 

(f)  The  DoD  Component's  proposed  project  acquisition  strategy  and  any  proposed 

waivers. 


(g)  The  Acquisition  Strategy  Report  (ASR)  discusses  the  basic  acquisition  strategy  being 
pursued.  As  part  of  the  IPS,  it  summarizes  the  entire  planned  program  structure  from  Demonstration 
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and  Validation  through  Production  and  Deployment.  Rer^ests  for  Proposals  (RFPs)  for  the  DenWal 
phase  may  not  be  released  until  the  MOA  has  approved  the  ASR.  The  ASR  is  nc4  to  be  confused  with 
the  Acquisition  Plan  which  only  describes  the  acquisition  strategy  for  the  upcoming  phase.  The  ASR 
should  discuss  the  transition  of  critical  technologies  in  technology  demonstration  programs  to  prototypes 
and  engineering  development  models,  plans  for  reducing  risk,  nondevelopment  items,  evolutionary 
acquisition,  and  preplanned  product  improvements  in  the  context  of  the  operational  requirements  and  the 
management  approach  to  the  acquisition. 

(h)  The  IPS  is  a  statutorily  imposed  requirement  prepared  by  the  project  manager.  The 
final  IPS  approved  by  the  SAE  will  be  submitted  to  the  DAB  Executive  Secretary  no  later  than  10 
working  days  prior  to  the  DAB  Committee  review. 

(i)  The  IPS  concept  will  be  used  by  the  DoD  Component  MDA  for  ACAT  1C,  II.  Ill  and  IV 
programs:  however,  the  documentation  content  should  be  appropriately  tailored  for  ACAT  II.  Ill  artd  IV 
programs.  DoD  5000.2M,  Part  4,  contains  preparation  procedures  and  format  (D58). 

f.  Functional  Plans.  In  addition  to  the  documents  required  for  MS  reviews,  there  are  a  number 
of  functional  plans  used  by  the  project  team  during  the  execution  of  each  acquisition  phase.  Some  of 
these  documents  are  not  reviewed  directly  by  the  MDA,  but  may  be  used  as  supporting  material.  They 
include  those  documents  used  by  the  project  office  to  actually  execute  the  project.  Scope  and  formality 
of  these  plans  vary  by  project  phase;  formats  for  some  may  be  specified  by  the  Air  Force. 

Table  E-4  Uilestone  I  Functional  Plans 
(A  narrative  explanation  of  functional  plans  may  be  found  in  P60) 

FUNCTIONAL  PLANS 

Integrated  Weapon  System  Master  Plan  (IWSMP) 

System  Engineering  Master  Plan  (SEMP) 

Systems  Engineering  Master  Schedule  (SEMS) 

Risk  Management  Plan  (RMP) 

Program  Protection  Plan  (PPP) 

Integrated  Logistics  Support  Plan  (ILSP) 

Polkjtion  Prevention  Action  Plan  (PPAP) 

Nuclear  Certification  Plan  (NCP)  (If  necessary) 

Cost  Analysis  Requirements  Descr^tion  (CARD) 

Program  Management  Plan  (PMP)  (May  be  used  on  non-major  programs,  generally  not  used  on 
major  programs) 

System  Security  Master  Plan  (SSMP) 

_ Computer  Ressources  Life  Cycle  Management  Plan  (CRLCMP) _ 


8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entance;  This  element  starts  when  the  project  team  has  received  final  input  from  Rountable 
III  (D67)  participants. 

b.  Exit:  This  element  is  complete  when  the  Roundtable  III  final  inputs  have  been  incorporated 
and  approval  to  forward  documents  to  the  Air  Force  has  been  received  (B22). 

(1)  Based  upon  the  inputs  from  Roundtable  III,  the  ASC  finalized  MS  Documents  and 
functional  plans  go  fonward  for  a  documentation  review  (B22).  This  documentation  review  serves 
as  the  vehicle  for  identifying  and  reviewing  any  major  questions  raised  by  the  draft  documentation  (not 
yet  approved  by  the  Air  Force  Acquisition  Executive  (AFAE))  and  any  new  program  developments  since 
the  planning  meeting. 


(2)  The  finalized  plans  are  provided  to  the  data  base  (D73)  where  a  centrally  managed 
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and  controlled  storage  area  is  provided  for  vaUdated  project  data.  This  database  contains  i^tdated  data 
used  to  describe  products  and  processes  and  provides  the  project  team  and  MDA  with  current  and 
historical  information  in  support  of  an  MS  decision. 


9.  KEY  INPUTS  AND  OUTPUTS: 

Ar 

a.  Inputs:  The  MS  0  AOM  and  Program  Management  Directive  (PMD)  (BIO)  are  key 
documentation  inputs.  The  PMD  directs  Phase  0.  development  of  the  COEA  and  the  ORD,  and 
identifies  the  required  documentation  and  schedule  considerations  for  the  next  MS.  The  key  inputs  for 
the  IPS  are  the  Mission  Need  Statement  (MNS);  the  results  of  the  Concept  Exploration  phase,  and  the  • 

ORD. 


b.  Outputs;  The  key  output  is  the  documentation/information  needed  by  the  MDA  to 
determine  if  the  results  of  Phase  0  warrant  establishing  a  new  acquisition  program  and  approval  to 
proceed  with  Demonstration  and  Validation  (Phase  I). 

10.  KEY  REFERENCES:  * 

a.  AF  Instruction  10-601,  Mission  Needs  arxf  Operational  Requirements  Guidance  and 
Procedures,  para  1 .4, 16  Feb  93.  This  instruction  provides  information  on  concept  studies,  COEA,  and 
MS  I  Documentation. 

b.  HO  Operating  Instruction  800-2  (draft).  Policy  and  Guidance  for  Preparing  PMDs,  para.  IV.,  1 
Jan  93.  This  instruction  contains  information  on  requirements/program  documents,  i..e.,  MNS,  ORD, 

COEA,  TEMP.  STAR.  PPP,  APB. 

c.  AFMC  Pamphlet  800-7,  Integrated  Acquisition  Strategy  Process,  Section  A,  Para  9,  20  Nov 
92.  This  pamphlet  contains  information  about  the  Operational  Roundtable. 

d.  ASR  Guide,  DSMC,  para.  4.4.2,  Jul  84.  This  guide  contains  lessons  learned  for  the 
approval  process. 

11.  IMPLEMENTATION  TOOLS: 

a.  In  document  preparation,  software  tools,  such  as  some  of  the  Defense  Systems  Management 
College  (DSMC)  nKxJels,  are  helpful  to  the  project  team  for  certain  specialized  tasks.  The  corripetition 
evaluation  module  is  used  in  evaluating  alternative  acquisition  strategies. 

b.  DSMC's  procurement  strat^y  model  (PSM)  works  by  comparing  the  proposed  project  to  past 

projects  stored  in  a  database.  It  identifies  and  he^s  eliminate  the  less  attractive  strategies  and  produces 
a  short  list  of  recommended  strategies  that  have  the  best  chance  for  meeting  the  project's  Initial  I 

Operating  Capability  (IOC)  and  cost  constraints.  The  model  also  allows  the  project  team  to  examine  the 

effects  of  changes  to  the  parameters  that  have  been  inputed  to  describe  the  project.  For  more 
infonnation  on  this  software  package,  contact  PMSS  Directorate/DRI-S.  Ft  Belvoir,  VA  22060-5426,  DSN 
354-4795/5783. 

c.  The  Consolidated  Acquisition  Reporting  System  (CARS)  provides  an  automated  tool  for  the  I 

preparation  c*  the  Selected  Acquisition  Reports,  Defense  Acquisition  Executive  Summary  and  the  APB 

which  are  all  used  to  support  the  MS  Decision  Review  Process. 

d.  Systems  200,  Acquisition  Planning  and  Analysis,  is  a  course  offered  thrcxjgh  The  Air  Force 
Institute  of  Technology  (AFIT).  This  course  has  a  Program  Documentation  Mcxfule  which  provides  an 

overview  of  the  regulatory  requirements  for  completing  the  ASR.  I 

e.  A  Ck)mputer  Based  Training  (CBT)  software  package  is  available  from  ASC/ALL,  513-257- 
1995,  for  use  in  developing  the  ILSP. 
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f.  The  database  is  the  project's  repository  of  information  compiled  in  a  central  location.  The 
data  contained  in  the  database  supports  appUcable  statutory  imposed  requiremerts,  and  meets  the 
information  needs  of  the  MDA,  supporting,  and  review  forums.  It  is  used  by  the  project  team  to  provide 
an  audit  trail  that  starts  with  the  User's  initial  request,  it  is  updated  at  key  points  in  the  life  of  the  project 
(D15,  031.  D44,  D49,  D73). 

g.  The  ASC/YX  Integrated  Flow  Chart  (IFC)  and  Process  Guide  is  an  important  implementation 
tool  for  the  project  team  to  use. 

12.  PLANNING  GUIDANCE: 

a.  DURATION: 

(1)  MS  documents  may  require  anywhere  from  8  weeks  to  8  months  to  prepare  and 
finalize  from  the  time  of  tasking.  Factors  such  as  priority,  complexity  and  coordination  cycle  or  level 
impact  the  duration  time.  Draft  MS  documents  are  due  to  OSD  59  days  prior  to  the  DAB.  The  MS 
documentation  review  is  44  days  prior  to  the  DAB  and  final  documents  are  due  to  OSD  24  days  before 
the  DAB.  The  final  documents  for  AFSARC  reviews  must  be  finalized  by  the  date  of  the  AFSARC. 

(2)  At  least  2  months  is  required  to  prepare  the  draft  IPS/ASR  for  the  documentation 
review.  Much  of  the  stand-alone  documentation  is  prepared  in  parallel.  The  final  IPS/ASR  is  submitted 
to  the  DAB  Executive  Secretary  NLT  1 0  working  days  prior  to  the  DAB  Committee  review. 

b.  CONSTRAINTS: 

(1 )  Restrictions  regarding  the  time  by  which  all  documents  must  be  completed. 

(2)  Restrictions  on  the  availability  of  needed  project  staff. 

(3)  Restrictions  on  the  availability  of  equipment  or  facilities  needed  to  complete  the 
documentation  package. 

(4)  Identification  of  other  organizations/individuals  with  which  you  must  interface. 

(5)  Restrictions  regarding  the  proper  format  in  which  the  documents  must  be  produced. 

C.  RESOURCES: 

(a)  Strategy  and  documents  Development  Team  (Technical  Manager,  Business 
Manager,  Logistician,  Contracting  Officer,  User  Representative  and  a  representative  from  HQ 
USAF/XOR  to  address  requirements,  a  representative  from  the  Test  community.  Special  Consultants, 
Communicator,  Administrative  Personnel). 

(b)  Two  man  months  (typically)  is  required  to  prepare  the  IPS/ASR  and  usually  in 
parallel  with  the  remaining  documentation. 

d.  LESSONS  LEARNED:  (Taken  from  DSMC  ASR  Guide,  see  key  refererx^es) 

(1)  As  early  as  possible  in  the  approval  process.  Project  Managers  should  identify 
prefect  opponents,  especially  those  with  veto  power.  Every  reasonable  effort  should  be  made  to  enlist 
their  support  through  such  methods  as  special  briefings  or  inclusion  on  project  team  advisory  panels. 

(2)  Project  teams  should  thoroughly  address  risk  assessment.  There  is  evidence  to 
suggest  that  this  is  the  most  important  review/approval  consideration  in  the  acquisition  strategy. 

(3)  Project  teams  should  determine  if  there  are  management  issues  that  should  be 
irx^luded,  in  addition  to  the  required  format  items.  These  current  topics  can  be  obtained  from  the 
appropriate  development  command  office  of  primary  responsibility. 

(4)  Project  teams  should  start  early  and  keep  an  auditable  document  trail.  They 
should  include  any  significant  guidance  they  received,  b<Xh  written  and  oral. 

(5)  Project  teams  should  ensure  that  their  documents  are  kept  current  by  using 
knowledgeable,  qualified  people  to  maintain  them  and  by  using  modem  word  procesing  equipment  to 
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enable  rapid  updating. 

e.  BEST  PRACTICES: 

(1 )  In  developing  the  required  documentation,  project  teams  should  keep  them  as  brief 
as  possi)le  to  depict  relevant  information,  without  adding  levels  of  detail  exceeding  that  re(;KJired.  For 
nonmajor  (ACAT II  through  IV)  programs,  documents  such  as  the  ORD  and  COEA  may  be  taikxed  to 
avoid  an  unnecessary  burden  on  the  preparers.  The  designated  MDA  will  direct  the  tailoring  of 
documentation  and,  if  proper,  waive  specific  documenation. 

(2)  The  project  manager  must  collaborate  tailoring  with  the  PEO;  provide  a  oontiruity 
of  advisors/approvers;  have  strategy  before  plans;  surrourKf  himself  with  functional  experts;  and 
encourage  disciplined  team  building/consensus. 

(3)  When  preparing  MS  documents  project  teams  must  review  and  affirm  user-stated 
needs,  and  the  adequacy  of  program  development  efforts  to  satisfy  those  needs  in  a  timely,  cost- 
effective  manner. 

(4)  The  Project  teams  must  rruintain  close  liaison  with  other  agencies  to  ensure  their 
preparation  activities  do  not  impede  project  planned  dates. 

(5)  To  ensure  all  requirement  documents  are  traceable  and  integrated,  project  teams 
need  to  use  the  dr^ment  numbering  system  described  in  AF  Instruction  1 0-601 ,  Missbn  Needs  and 
Opertional  Requirements  Guidance  and  Procedures,  Atchs  4,  5,  and  6, 16  Feb  93. 

(6)  It  is  essential  that  the  COEA  activity  be  documented  and  archived  for 

future  reference  and  use  as  the  starting  point  for  subsequent  COEAs  for  the  Milestone  II  data  package. 

(7)  Point  of  Contact  for  MS  documents  is  SAF/AOXA,  DSN  225-5973. 


f.  TRAPS:  Constrain  plan  writers  -  do  not  permit  each  function  or  discipline  to  create  its  own 
ground  rules  and  generate  unconstrained  plans.  The  end  result  of  this  kind  of  approach  is  a  mass  of 
unrelated  data,  which  at  some  point  (usually  critical  to  the  schedule)  has  to  be  restored  and  repackaged. 
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1.  ELEMENT:  069,7881.3.3.5  (IFC93-3) 

2.  ELEMENT  TITLE:  Release  Request  for  Proposal  (RFP) 

3.  ELEMENT  OWI«R(S):  Contracting  Activity  PK 
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4.  ELEMENT  STAKEHOLDER(S):  Program/Project  Manager  (PM),  Buying  Office  Contracting  Office, 
Program/Project  Team  (Cadre),  Functional  Office  Representatives,  Legal  Office,  Local,  Center  and 
Headquarters'  Business  and  Contract  Clearance  Offices,  Source  Selection  Auttx>rily  (SSA),  Designated 
Acquisition  Commander  (DAC)/Program  Executive  Officer  (PEO)  (if  identified),  Un^rsecretary  of 
Defense  for  Acquisition  (USO(A)). 

5.  REQUIREMENT: 

a.  FAR  1 5.408  -  Provides  policy  and  procedures  on  issuing  solicilations 

b.  AFMC  FAR  Sup  5315.408  -  Provides  policy  and  procedures  on  issuing  solicitations 

c.  AFFARS  5301 .9007  --  Provides  policy  and  procedures  on  solicitation  reviews 

d.  AFMC  FAR  Sup  5301 .9007  -  Provides  policy  and  procedures  on  solicitation  reviews 

e.  AFFARS  5301 .601 -95(a)  -  Provides  policy  and  procedures  on  legal  reviews 

f.  AFMC  FAR  Sup  5301.601-94  -  Provides  policy  arfo  procedures  on  legal  reviews 

g.  AFMCR  70-7  -  Establishes  criteria  for  conducting  Solicitation  Review  Boards  (SRBs) 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  The  purpose  of  this  element  is  to  release  an  RFP  from  which  industry  can  prepare  and 
submit  a  proposal. 

b.  Objectives:  The  objective  is  to  have  the  RFP  proceed  through  its  review/approval  process,  obtain 
approval  for  its  release  and  issue  it  to  irfoustry 

7.  DESCRIPTION: 

a.  After  the  Draft  RFP  has  been  finalized  into  the  final  RFP  (D64),  there  is  a  review/approval 
process  the  RFP  must  complete  prior  to  Ks  release.  The  length  and  complexity  of  the  review 
process/approval  depends  on  the  dollar  value  and  the  classification,  (i.e.  Major/Selected  Program,  Other 
Program,  Other  Contracting)  of  the  program/project.  In  addition  to  the  review/approval  requirements 
listed  in  ASC/PK  Policy  Letter  93-004, 27  Jan  93.  the  review/approval  process  can  include,  based  on  the 
particular  action,  a  review  by: 

-  a  Solicitation  Review  Board  (SRB)  (AFMCR  70-7) 

-  the  Source  Selection  Management  Group  (SSMG)  (if  competitive)  (AFR  70-15/-30), 

-  Source  Selection  Advisory  Council  (SSAC)/SSA  approval  of  the  RFP  release  (if  competitive), 

-  Assistant  Secretary  of  the  Air  Force  for  Ac^isition  (ASAF(A))  (B17)  (AC AT  I  programs/projects) 

-  USD(A)  (for  ACAT  I  programs/projects)  (A1 5)  and 

-  A  sign^  PEO  (if  assigned)  release  letter. 

These  reviews/approvals  are  called  out  in  the  above  Requirements  section  documents.  During  this 
review  process,  the  reviewers  examine  not  only  the  RFP  document  but  also  the  file  accompanying  the 
RFP,  to  ensure  pertinent  documentation,  (i.e.  program  synopsis  in  the  Commerce  Business  Daily, 
approved  acquisKion  plan.  Justification  and  A^roval  (J&A)  for  noncompetitive  programs.  Source 
Election  Plan,  etc.)  has  been  completed  and  included.  Subsequent  to  the  review/approval  process 
described  above,  the  RFP  may  be  released. 
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b.  The  length  of  time  the  RFP  is  released  to  industry  tor  proposal  preparation  is  determined  by  the 
complexity  of  the  acciuisition.  Other  factors  migH  include  wh^tw  a  draft  RFP  was  used  and  whether 
the  RFP  changed  substantially  from  draft  to  final.  The  time  should  not  be  less  than  45  days  and 
normally  60  days.  (These  times  are  ASC  standards  and  can  be  adjusted  accordingly  depending  on  the 
complexity  of  the  acquisition.)  During  that  time,  industry  prepares  its  proposals  which  will  be  used  as  a 
basis  from  which  to  award  a  contract,  either  by  the  formal  source  selection  process  tor  competitive 
acquisitions  or  by  the  negotiation  process  for  noncompetftive  acquisitions.  This  activity  then  ftows  toto 
the  effort  descriM  in  070. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance:  The  RFP  cannot  be  released  until  the  applicable  reviews  mentioned  above  have 
occurred  and  the  Source  Selection  Plan  (H  required)  has  been  approved  and  the  Acquisition  Plan  has 
been  reviewed  arto  approval  to  release  the  RFP  has  been  given. 

b.  Exit:  Criteria  for  exiting  this  action  is  when  the  RFP  has  been  released  to  industry  tor  an  offeror 
to  prepare  a  proposal  in  response  to  the  RFP  and  government  personnel  have  been  notified  to  cease 
discussions  with  all  offerors  and  to  direct  any  queries  to  the  Contracting  Officer  (D70). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Input:  The  inputs  are  the  applicable  RFP  compiiarx:e  and  programmatic  reviews  listed  in 
Paragraph  7  above  required  prior  to  the  RFP  release. 

b.  Output:  The  output  is  the  formal  RFP  released  to  industry. 

10.  KEY  REFERENCES: 

a  ASC/CYX's  "A  Schedule  for  Acquisition  Planning.  Initial  Acquisition  and  Strategy  Development 
Through  Source  Selection*  contains  a  schedule  on  the  timing  of  the  review  process  and  release  of  the 
RFP. 

b.  HQ  AFSC  Request  for  Proposal  Process  Guide  provides  guidance  on  review  and  release  of  the 
RFP. 

c.  ASC  FAR  Sup  5315  408  -  Provides  policy  and  procedures  on  issuing  solicitations  . 

d.  ASC  FAR  Sup  5301 .9007  --  Provides  policy  arxl  procedures  on  solicitation  reviews. 

e.  ASC  FAR  Sup  5301  601 -94(b)  -  Provides  policy  and  procedures  on  legal  reviews. 

f.  DOD  Directive  5000.2  -  Defense  Acquisition  Management  Policies  and  Procedures,  Change  1 , 10 
Mar  93,  Part  2.C.2  provides  guidance  on  solicitation  reviews  prior  to  release  for  Acquisition  Category  I 
programs. 

g.  AFR  70-15,  Formal  Source  Selection  for  Major  Acquisitions  (AFFARS  Appendix  AA)  -  contains 
requirements  for  pre-source  selection  reviews  and  approval. 

h.  AFR  70-30,  Streamlined  Source  Selection  Procedures  (AFFARS  Appendix  BB)  -  contains 
requirements  for  presource  selection  reviews  and  approvals. 

1 1 .  IMPLEMENTATION  TOOLS:  ASC/PKC  has  a  review  checklist  which  can  be  used  to  ensure  the 
RFP  file  is  complete  and  the  RFP  is  adequately  prepared  and  ready  to  be  reviewed.  The  HQ  AFSC  RFP 
Process  Guide  listed  above  can  also  be  reviewed  prior  to  the  review  cycle  to  ensure  its  guidance  is 
included  in  the  RFP. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  This  element  is  Program/Projecl  dependent,  however,  the  ASC/CYX  "Schedule 
for  Acquisition  Planning"  contains  a  generic  time  schedule  for  the  events  leading  up  to  and  issuing  the 
RFP.  The  schedule  guide  shows  an  average  time  of  60  days  from  when  the  formal  RFP  is  complete 
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until  its  release.  It  also  includes  another  60  days  as  the  average  time  tor  offerors  to  prepare  and  submit 
their  proposals.  This  time  is  also  dependent  on  the  Program/Project. 

b.  CONSTRAINTS:  The  source  selection  plan  and  the  acquisition  plan  need  to  be  approved 
prior  to  release  of  the  RFP. 

c.  RESOURCES:  The  personnel  normally  required  for  issuing  the  RFP  are  the  PM  and  the 
Contracts  representative.  All  of  the  other  tonctional  represerrtatives  have  already  made  their  input  to  the 
document:  however,  additional  input  may  be  required  if  there  are  any  changes  required  as  a  result  o(  the 
review/approval  process.  The  time  required  for  the  resources  is.  again,  dollar  value  or  program/project 
dependent.  The  time  and  resources  will  be  greater  tor  a  high  dollar  arvi/or  ACAT I  progranvprofect  than 
it  will  tor  a  lower  dollar/designated  program  sirtce  the  ACAT  I  program/project  RFP  wifl  be  subject  to 
more  reviews/approvate. 

d.  LESSONS  LEARNED: 

(1 )  Allow  adequate  time  in  the  planning  schedule  for  this  task  since  most  of  the 
review/approval  process  is  not  controlled  by  the  program/project  office  and  usually  takes  loriger  than 
expected.  This  can  be  especially  true  if  it  is  an  ACAT  I  program/project  which  will  have  to  go  to  the 
ASAF(A)  (B1 7)  and  USD(A)  (A1 5).  Nominal  times  tor  ASC's  RFP  activities  are  listed  in  the  Procurement 
Management  System  (PMS)  (ASC/PK  contract  management  data  base)  (DSN  785-7450). 

(2)  Allow  adequate  time  (45  to  60  days)  for  the  offeror  to  prepare  an  adequate  proposal 
from  which  to  evaluate  during  source  selection  or  on  which  to  base  negotiations  in  a  noncompetitive 
acquisition.  If  the  offeror  is  not  allowed  sufficient  time  and  submits  a  proposal  which  is  not  adequate,  the 
time  spent  going  back  and  asking  questions  corKeming  its  deficiencies  or  having  the  proposal  rewritten 
can  be  greater  than  allowing  adequate  time  initially.  Often  times,  industry  prepares  its  proposal  based  on 

f  the  Draft  RFP  and  uses  the  formal  RFP  to  update  and  give  a  final  check  to  the  proposal. 

(3)  Involve  the  Product  Center  PK  RFP  reviewers  (ASC/PKC)  as  part  of  the  RFP  team. 
By  the  reviewer  gaining  knowledge  of  the  program/project  early  on,  time  will  be  saved  when  it  is  time  for 
the  RFP  to  be  reviewed. 

(4)  ASC/CYX  has  a  lessons  learned  data  base  including  RFP  and  source  selection 
lessons  learned  which  they  periodically  update. 

e.  BEST  PRACTICES: 

(1 )  In  the  past,  it  was  usually  the  PM  and  a  Contracts  representative  who  were  involved 
in  issuing  the  RFP.  Using  the  Independent  Product  Team  (IPT)  approach  in  getting  the  RFP  reviewed 
and  issued  is  more  beneficial.  As  members  of  the  team,  rather  than  individuals,  they  have  been  working 
tor  some  time  in  preparing  the  RFP  and  should  know  the  whole  document  and  may  offer  constructive 
advice  to  disciplines  other  than  their  own.  They  will  also  be  better  aUe  to  tie  together  inter  discipline 
activities.  They  should  continue  to  work  together  as  a  team  for  the  PM  whenever  he  needs  their 
assistance  in  getting  the  document  issued. 

(2)  The  RFP  team  is  responsible  for  the  timeliness  and  quality  of  the  RFP.  Guard 
against  relying  too  much  on  reviews  and  too  little  upon  building  in  quality  during  preparation.  Include  all 
the  required  information  at  the  beginning.  It  will  take  less  time  in  the  review  process  if  it  is  done  right 
initially. 


(3)  Sometimes,  depending  on  the  acquisition.  Roundtable  III  of  the  Integrated 
Acquisition  Strategy  Process  (lASP),  can  take  the  place  of,  or  be  combined  with,  the  Solicitation  Review 
Board  (SRB)  (see  paragraph  5,  Requirements).  If  an  SRB  reviews  the  Draft  RFP,  that  review  can  serve 
as  the  requirement  for  an  SRB  on  the  formal  RFP  if  no  major  changes  have  occurred  during  that  time. 
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(4)  If,  during  offeror  propoeal  preparation  time,  the  offeror(s)  request  additionai  time  for 
them  to  prepare  their  proposal,  weigh  the  request  carefuMy.  If  additional  time  can  be  alowed  without 
jeopardizing  the  program^^roiect  schedule,  the  time  should  probably  be  allowed.  It  could  save  time  in 
the  long  run  by  not  having  to  ask  questions  due  to  an  inade^ate  proposal.  This  time  extension,  if 
granted,  appli^  to  all  offerors. 

(5)  When  timelines  are  tight,  use  of  an  iruvemental  review  process  could  save  time. 

One  review  group  may  begin  prior  to  completion  by  another  group. 

(6)  Have  continuity  of  RFP  team  members  throughout  the  RFP  preparation.  Select  the 
members  so  they  are  avaMable  throughout  the  RFP  preparation  process  and  also  serve  as  members  of 
the  source  selection  team. 

(7)  Gk^ing  to  an  all  electronic  RFP  and  proposal  submittal  will  greatly  save  time.  Some 
Centers  have  already  initiated  this  activity. 

f.  TRAPS:  You  must  research  and  determine  which  reviews  and  approvals  are  required  for  your 
acquisition  and  complete  all  of  them  or  release  of  your  RFP  could  be  delayed. 
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1.  ELEMENT:  070,  TBS  1 .3.3.6  (IFC  93-3) 

^  2.  ELEMENT  TITLE:  Conduct  Source  Selection  (Conipetitive)/Conduct  Negotiations  (NonCompelilive) 

3.  ELEMENT  OWNERS:  Project/Program  Offices 

4.  ELEIMNT  STAKEHOLDERS:  ASC/PK,  CY.  EN,  AL.  and  FM 

5.  REQUIREMENTS: 

a.  Federal  Acquisition  Regulation  (FAR)  Subpart  6.3,  Other  than  Full  and  Open  Competition,  and 
applicable  supplements.  FAR  Subpart  6.3  provides  policies  and  procedures,  and  identifies  statutory 
authorities  for  contracting  without  providing  for  full  and  open  competition. 

b.  FAR  Part  15,  Contracting  By  Negotiation,  and  applicable  supplements.  FAR  Part  15  provides 
policies  and  procedures  for  contracting  for  supplies  and  services  by  ne$^iation. 

c.  AF  Regulation  (AFR)  70-1 S/AFFARS  Appendix  AA,  27  Apr  88.  Formal  Source  Selection  for 
Major  Acquisitions,  and  amicable  supplements.  AFR  70-1 5  provides  policies  and  procedures  for 
soliciting  and  evaluating  offeror's  proposals  for  major  acquisitions,  and  implements  FAR  Subpart  15.6, 
Source  Selection  for  Major  Acquisitions. 

d.  AFR  70-30/ AFFARS  Appendix  BB.  27  Apr  88,  Streamlined  Source  Selection  Procedures,  and 
applicable  supplements.  AFR  70-30  provides  streamlined  procedures  for  source  selections  which  fall 
below  the  dollar  thresholds  or  are  outside  the  scope  of  conipetitive  negotiated  procurements  described  in 
AFR  70-15. 

6.  PURPOSE/OBJECTIVES: 

I 

a.  Purpose:  The  purpose  of  conducting  a  source  selection  for  a  con^titive  acqueition  is  to 
evaluate  industry  proposals  received  in  response  to  a  Request  for  Proposal  (RFP),  and  as  a  result  of  the 
evaluation,  determine  which  contractor's  proposal  best  meets  government  requirements  at  a  fair  and 
reasonable  price.  In  a  noncompetitive  acquisition,  negotiations  are  conducted  with  the  offeror  to  reach 
agreement  on  all  terms  and  conditions  of  the  contract,  and  to  arrive  at  a  price  that  is  both  fair  and 
reasonable. 

b.  Objectives;  The  objective  of  the  source  selection  process  is  to  award  a  contract  to  the  offeror 
who,  based  on  their  proposal,  is  best  qualified  to  fulfill  the  government's  requirements  at  a  fair  and 
reasonable  price.  The  objective  of  conducting  negotiations  in  a  noncomp^itive  acquisition  is  to  reach 
agreement  on  all  aspects  of  the  contract  including  terms,  conditions,  and  pricing  arrangements. 

7.  DESCRIPTION: 

a.  The  source  selection  process  begins  with  the  release  of  an  RFP  to  industry  after  approval  is 
received  from  the  SSA.  At  the  time  the  RFP  is  released,  a  notice  indicating  a  source  selection  action  is 
in  process  must  be  provided  to  all  contractors  receiving  the  RFP,  arxj  to  all  participants  on  the  source 
selection  team.  The  chairperson  of  the  Source  Selection  Advisory  Council  (SSAC)  is  the  irxlividual 
responsbie  for  the  release  of  the  notice  on  major  acquisitions,  and  for  less-than-major  acquisitbns,  the 
Contracting  Officer  is  responsible  for  ensuring  the  notice  of  the  source  selectbn  action  is  accomplished. 
The  notice  identifies  the  system,  subsystem,  or  project  involved,  the  anticipated  period  of  the  source 
selection,  and  includes  a  statement  cautioning  participating  offerors  that  contacts  with  source  selection 
team  members  are  not  aibwed.  Members  of  the  source  selectbn  team  and  all  potential  offerors  must  be 
informed  that  the  Contracting  Offber  is  the  only  individual  authorized  to  contact  potential  offerors,  and 
the  SSA  is  the  only  person  authorized  to  rebase  informatbn  regarding  an  ongoing  source  selectbn. 


f. 


•  • 


D-557 


1_ I_ t_ S •  -  • f  S  t 


New  S3 


b.  With  the  formal  release  of  the  RFP  to  irxjustry,  the  project  team  mu3  be  prepared  to  answer 
questions  that  may  arise  in  regard  to  the  specifications  or  other  nontechnical  requirements  of  the 
^icMation.  For  projects  with  highly  complex  specifications,  the  project  team  may  choose  to  conduct  a 
preproposal  conference  after  the  RFP  has  been  released,  but  prior  to  receipt  of  corttractor  proposals. 
Generally,  the  purpose  of  the  conference  is  to  explain  or  clarify  complicated  requirements,  arxf  allow 
contractors  an  opportunity  to  ask  questions  in  regard  to  the  solicitation.  The  Contracting  Officer  is 
responsible  for  ensuring  that  alt  prosp^ive  offerors  receive  timely  notification  of  the  conference,  that  all 
prospective  offerors  receive  the  same  information  concerning  the  acquisition,  that  a  complete  record  of 
the  conference  is  prepared,  and  that  all  prospective  offerors  receive  a  copy  of  that  record.  The 
Contracting  Officer  must  also  caution  all  prospective  offerors  that  any  remarks  or  explanations  given  at 
the  confererrce  shaH  not  qualify  the  terms  of  the  RFP,  and  that  the  terms  of  the  solicitiation  and 
specifications  remain  unchang^  unless  the  RFP  is  amended  in  writing.  Even  if  a  preproposal 
conference  is  not  corxlucted  for  a  solicitation,  questions  and  concerns  raised  by  prospective  offerors 
must  still  be  addressed.  The  project  team  must  ensure  that  any  additional  information  provided  to  one 
offeror,  as  a  result  of  questiorrs  or  concerns  raised,  must  also  be  provided  to  all  prospective  offerors.  All 
questions  received  from  contractors  must  be  in  writing,  and  based  on  the  questions  received,  it  may  be 
necessary  for  the  project  team  to  amerfo  the  RFP.  Amendments  would  be  required  to  identify  charrges  in 
quantity,  specifications,  or  delivery  schedules,  to  correct  defects  or  ambiguities,  or  to  extend  the  closing 
date  for  receipt  of  proposals  from  contractors.  Any  amendments  issued  must  be  in  writirtg  to  all 
contractors  who  received  the  RFP. 


c.  Prior  to  the  receipt  of  contractor  proposals,  the  acquisition  team  must  establish  evaluation 
standards,  arfo  ensure  the  standards  are  approved  before  the  evaluation  of  proposals  can  begin.  The 
evaluation  standards  designate  the  minimum  performance  or  compliance  with  requirements  that  a 
proposal  must  meet  to  be  considered  acceptable  to  the  government.  Contractor  proposals  are  evaluated 
against  the  standards  to  determine  the  level  of  compliance  with  the  requirements.  The  evaluation 
standards  must  be  developed  as  a  stand  -alone  document,  and  the  standards  are  not  to  be  included  in 
either  the  request  for  proposal  or  source  selection  plan.  The  evaluation  standards  must  be  marked  as 
’Source  Selection  Information/For  Official  Use  Only  -  Source  Selection  Sensitive,’  and  treated 
accordingly. 

d.  The  actual  evaluation  process  begins  with  the  recefot  of  contractor  proposals  in  a  secure 
environment  by  the  project  office.  As  proposals  are  received,  the  date  and  time  of  receipt  is  recorded  on 
each  proposal.  Eact.  proposal  must  be  received  by  the  date  and  time  specified  in  the  RFP,  or  the 
proposal  will  be  deem^  ineligible  for  consideration  for  award  (see  Federal  Acquisition  Regulation,  Part 

1 5.  Subpart  1 5.4,  paragraph  1 5.41 2(c)  for  exceptions  to  acceptaice  of  late  submittals).  Upon  receipt  of 
a  late  proposal,  the  Contracting  Officer  must  notify  the  offeror  that  the  proposal  is  ineligible  for 
consideration  due  to  late  arrival.  After  contract  award,  the  late  proposal  will  be  filed  with  any  other 
unsuccessful  proposals  evaluated  by  the  project  office  . 

e.  Contractor  proposals  that  are  submitted  in  accordance  with  the  date  and  time  specified  in  the 
RFP  are  usually  evaluate  twice  by  the  source  selection  team.  An  initial  evaluation  is  conducted  before 
the  competitive  range  determination  is  made,  and  a  more  in-depth  evaluation  is  performed  after  that. 

The  second  evaluation  takes  place  after  the  offerors  have  updated  their  proposals  in  response  to  the 
request  for  Best  and  Final  Offers  (BAFOs).  For  those  acquisitions  that  are  awarded  based  on  a 
contractor's  original  proposal  (award  without  discussion),  a  second  evaluation  is  not  conducted.  The 
initial  evaluation  of  proposals  involves  a  technical  and  cost/price  evaluation,  and  when  applicable,  a 
review  of  management,  manufacturing,  logistics  and  test  portions  of  proposals  may  be  conducted,  along 
with  a  risk  assessment  of  each  proposal.  As  team  members  evaluate  proposals  against  the  standards, 
any  strengths  or  weaknesses  identified  in  the  proposals  are  documented  in  a  narrative  analysis  to 
support  the  findings.  Also,  during  the  initial  evaluation  of  proposals,  evaluators  must  document  any 
deficiencies  cited  in  the  proposal.  Deficiencies  are  recognized  as  any  area  of  the  contractor's  proposal 
that  fails  to  meet  the  government's  minimum  level  of  compliance  as  defined  in  the  evaluation  starxlards. 
Deficiency  reports  should  be  prepared  separately  from  the  narrative  analysis  of  strengths  and 
weaknesses  cited  in  the  proposals,  and  should  include  the  impact  an  uncorrected  deficiency  could  have 
on  the  project.  Contractors  are  notified  of  deficiencies  in  their  proposal,  and  given  a  reasonable 
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^  opportunHy  to  resolve  the  deficiencies  after  the  competitive  range  has  been  determined.  During  the 

W  initial  evaluation  of  proposals,  it  may  also  be  necessary  to  have  contractors  clarify  parts  of  their  proposal 

due  to  lack  of  information,  contradictory  statements  contained  within  the  proposal,  or  because  clericai 
errors  have  caused  conkjsion  as  to  the  actual  intent  of  a  statement.  Unlike  deficiency  reports,  ' 

clarification  rec^ests  that  do  not  warrant  discussions  with  a  contractor  may  be  issued  to  the  respective 
contractor  prior  to  the  competitive  range  determination. 

f.  The  Contracting  Officer  bases  the  competitive  range  determination  on  the  narrative  analysis  of 
the  initial  evaluation  of  proposal  strengths  and  weaknesses,  along  with  any  deficiencies  cited  in  a 

proposal,  the  potential  for  the  deficiency  to  be  corrected,  and  price.  The  determination  identifies  those  > 

contractors  who  stand  a  reasonable  chance  for  selection  of  contract  award  based  upon  the  initial 

evaluation  of  proposals.  Whenever  there  is  doubt  to  whether  a  proposal  has  a  chance  for  selection  of 

award,  the  proposal  should  be  included  in  the  competitive  range.  Oix:e  contractors  are  identified  as 

being  within  the  competitive  range,  discussions  may  begin. 

g.  The  Contracting  Officer  conducts  discussions  with  all  contractors  within  the  competitive  range  i 

through  written  and/or  oral  communications.  These  discussions  ensure  there  are  no  misunderstarxtings 

remaining  prior  to  the  final  evaluation  of  proposals  and  selection  of  contract  award.  During  discussions, 
the  contracting  officer  discloses  any  deficiencies  cited  in  the  contractors'  proposals.  The  Contracting 
Officer  also  requests  clarification  for  any  unclear  area  in  a  proposal  from  lack  of  information,  conflicting 
statements,  or  clerical  errors.  Once  discussions  are  concluded  with  all  offerors,  the  Contracting  Officer 
issues  written  requests  for  Best  and  Final  Offers  (BAFOs).  The  call  for  BAFOs  enables  contractors  ^ 

sufficient  time  to  correct  any  deficiencies  in  their  original  proposal  and  to  clarify  any  conflicling 
statements  identified  to  them  by  the  Contracting  Officer.  Offerors  are  advised  that  any  changes  to  their 
original  proposal  must  be  supported  by  rationale  for  the  change,  and  that  all  revisions  are  due  by  a 
common  cut-off  date  specified  in  the  notification  for  best  and  final  offers.  The  second  evaluation  of 
proposals  occurs  when  contractors  submit  their  best  and  final  offers.  The  evaluation  after  BAFO  receipt 
is  only  on  changes  made  by  the  offeror  in  his  BAFO  response.  The  BAFO  responses  are  evaluated  by 
p  the  team,  and  any  changes  that  occur  to  the  technical  and/or  cost  ratings  of  the  original  proposals  are  * 

documented. 

h.  Once  the  evaluation  of  BAFOs  is  complete,  and  all  the  necessary  reports  and  briefings  are 
presented  to  the  SSA,  the  award  decision  can  be  made.  (See  the  AF  Regulations  70-1 5  and  70-30  for  a 
compile  description  of  the  documents,  reviews,  and  briefings  required  for  the  different  categories  of 

acquisitions.)  The  SSA  will  base  the  award  decision  on  the  information  documented  from  the  evaluation  i 

of  proposals,  discussions  with  offerors,  and  the  best  and  final  offer  results.  After  the  SSA  has  selected 
the  awardee  for  an  acquisition,  a  Source  Selection  Decision  Document  is  prepared  for  SSA  signature. 

The  source  selection  decision  document  identifies  the  contractor  selected,  the  system  title,  RFP  number, 

the  rationale  used  in  support  of  the  decision,  and  describes  the  basis  for  the  decision  in  terms  of 

beneficial  value  to  the  government.  After  the  source  selection  authority  signs  the  source  selection 

decision  document,  it  is  forwarded  to  the  Contracting  Officer  for  the  formal  execution  of  the  contract  (see  i 

data  sheet  D74). 

i.  While  paragraphs  7a-h,  above,  provide  general  guidance  on  conducting  a  source  selection  for 
competitive  acquisitions,  there  are  noncompetitive  procurements  that  follow  a  different  set  of  procedures. 

Prior  to  conducting  a  sole  source  acquisition,  the  project  team  must  determine  if  the  acquisition  meets 

the  statutory  requirements  set  forth  in  FAR  Subpart  6.3,  Other  than  Full  and  Open  Competition.  If  it's  . 

determined  the  acquisition  is  supported  by  one  of  the  authorities  cited  in  Subpart  6.3,  the  project  team 
may  proceed  under  the  procedures  for  noncompetitive  acquisitions.  All  noncompetitive  procurements 
must  have  written  justification  substantiating  the  team's  need  to  award  a  contract  on  a  sole  source  basis. 

The  justification  for  other  than  full  and  open  competition  rrHist  cite  the  specific  authority  referenced  in 

Subpart  6.3,  along  with  identifying  the  contracting  activity,  the  supply  or  service  to  be  provided,  a 

description  of  why  the  contractor's  unique  qualifications  fall  under  the  authority  cited,  and  a  statement 

that  the  cost  to  the  government  will  be  fair  and  reasonable.  After  the  justification  is  prepared,  it  must  be  * 

approved  prior  to  conducting  negotiations  with  the  prospective  contractor  (see  FAR  Subpart  6.3  for  a 

breakdown  of  approval  levels).  The  negotiations  between  the  project  team  and  the  contractor  are 
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conducted  to  reach  an  agreement  on  all  aspects  of  the  proposal,  inclucfing  terms  and  conditions,  and  the 
pricing  arrangements.  C^e  the  negotiations  are  complete,  the  contract  award  process  begirrs  (see  Data 
Sheet  74). 

8.  EMTRANCE/EXIT  CRITERIA: 

a.  Errtrance:  The  source  selection  process  begins  when  the  Request  for  Proposal  (RFP)  is 
released  to  industry  (see  Data  Sheet  D69). 

b.  Exit;  For  competitive  acquisitions,  the  source  selection  process  ends  with  the  award  of  the 
contract(s),  and  on  noncompetitive  acquisitions  the  process  is  corriplete  at  the  conclusion  of  negotiations 
(see  Data  Sheet  D74). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  key  inputs  for  the  source  selection  process  are  the  Source  Selection  Plan  (SSP), 
and  the  receipt  of  contractor  proposals  for  evaluation.  The  project  office  is  responsible  for  devolving  of 
the  SSP,  and  ensuring  plan  approval  by  the  source  selection  authority  prior  to  the  release  of  the  request 
for  proposal  to  industry.  The  source  selection  plan  is  instmmental  in  the  evaluation  process  because  H 
provides  the  source  selection  team  the  criteria  and  procedures  required  to  conduct  the  source  selection. 
For  a  more  detailed  description  of  the  source  selection  plan  and  its  purpose,  see  data  sheet  D62. 

Industry  proposals  are.  of  course,  necessary  for  the  solicitation  to  evolve  into  an  actual  program. 
Contractors  prepare  their  proposals  based  on  government  requirements  as  described  in  the  request  for 
proposal.  After  preparation,  the  proposals  must  be  sumitted  to  the  project  office  by  the  date  arid  time 
specified  in  the  RFP.  For  a  detailed  description  of  the  RFP  and  its  release  to  industry,  see  data  sheets 
D64  and  D69. 

b.  Outputs;  For  competitive  acquisitions,  the  key  output  in  the  source  selection  process  is  the 
source  selection  decision  document  that  identifies  the  awardee  of  a  contract.  The  source  selection 
decision  document  must  be  signed  by  the  SSA  prior  to  the  document  being  forwarded  to  the  project 
office.  Receipt  of  the  signed  source  selection  decision  document  gives  the  Contracting  Officer  the 
authority  to  execute  the  formal  contract  (see  data  sheet  D74).  For  noncompetitive  acquisitions,  the  key 
output  is  the  formal  contract  issued  by  the  project  office  at  the  conclusion  of  negotiations. 

10.  KEY  REFERENCES: 

a.  Federal  Acquisition  Regulation  (FAR)  Subpart  6.3,  Other  Than  Full  and  Open  Competition, 
and  applicable  supplements.  FAR  Subpart  6.3  provides  policies,  procedures,  and  statutory  authorities 
for  contracting  without  full  and  open  competition. 

b.  Federal  Acquisition  Regulation  (FAR)  Part  15,  Contracting  By  Negotiation,  and  applicable 
supplements  (see  paragraph  5,  above,  for  a  brief  description  of  policies  covered  under  FAR  Part  1 5). 

c.  Air  Force  Regulation  70-15/AFFARS  Appendix  AA,  27  Apr  88,  Formal  Source  Selection  for 
Major  Acquisitions,  and  applicable  supplements  (see  paragraph  5,  above,  for  a  brief  description  of 
policies  covered  under  AFR  70-1 5). 

d.  Air  Force  Regulation  70-30/AFFARS  Appendix  BB,  27  Apr  88,  Streamlined  Source  Selection 
Procedures,  and  applicable  supplements  (see  paragraph  5  above,  for  a  brief  description  of  policies 
covered  under  AFR  70-30). 

e.  A  Schedule  for  Acquisition  Planning;  Initial  Acquisition  and  Strategy  Development  through 
Source  Selection,  Jan  92,  Prepared  by  ASD/CYX.  This  document  describes  the  tasks  that  a 
project/program  office  must  accomplish  from  new  start  review  through  RFP  release,  source  selection. 
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and  first  Post-Award  Conference.  The  document  also  contains  a  brief  description  of  what  each  major 
task  or  review  entails,  along  with  detailed  breakdowns  of  the  tasks  in  certain  areas. 

11.  IMPLEMENTATION  TOOLS:  The  project  team  should  have  the  documents  referenced  above,  in 
paragraph  10.  available  for  use  throughout  the  acquisition  cycle.  The  documents  provide  in-d^h 
guidance  on  the  entire  source  selection  process,  the  arrangement  and  responsibUMes  of  the  various 
source  selection  organizations  (i.e..  Source  Sel^ion  Evaluation  Team  [SSET],  SSAC,  etc.),  along  with 
providing  invaluable  examples  of  standards,  source  selection  reports,  arxl  listings  of  major  source 
selection  events. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  desired  time  frame  for  source  selection  is  120  days  from  the  time  the  RFP 
is  released  to  industry  until  the  award  decision  is  made.  It  may  be  necessary,  however,  to  adjust  the 
schedule  based  on  the  level  of  complexity  of  the  project.  Any  adjustments  in  the  schedule  beyond  the 
number  of  days  approved  in  the  Source  Selection  Plan  (SSP)  must  be  supported  by  written  justification, 
and  submitted  to  the  appropriate  approval  level  for  the  acquisition. 

b.  CONSTRAINTS:  Some  constraints  associated  with  the  source  selectbn  process  involve  the 
difficulty  in  scheduling  qualified  individuals  to  serve  as  evaluation  team  members,  or  as  advisors  for  the 
source  selection.  Most  source  selections  require  full-time  resources  who  can  be  available  to  perform 
their  responsibilities  at  a  given  time.  If  source  selection  team  members  are  committed  to  numerous 
other  work-related  activities,  it  may  be  difficult  for  them  to  rovide  the  type  of  support  desired.  On  major 
acquisitions,  it  may  be  difficult  to  schedule  time  when  all  members  of  the  Source  Selection  Advisory 
Council  (SSAC)  are  available  to  meet. 

C.  RESOURCES: 

(1)  The  level  and  complexity  of  a  project  will  determine  the  exact  make-up  of  a  source 
selection  organization.  In  general,  the  evaluation  team  would  be  comprised  of  individuals  from  the 
technical  and  contracting  fields,  and  should  include  representatives  from  each  of  the  functionals. 
Dependent  upon  the  project,  representatives  may  be  required  from  support  organizations  such  as  the 
ALCs,  and  the  user  may  also  be  involved  in  the  evaluation.  Also,  based  on  the  complexity  of  the 
project  and  the  resultant  proposals,  the  source  selection  organization  may  include  an  advisory  group  to 
provide  support  and  guidance  to  the  evaluation  team,  and  in  turn,  provide  advice  and  assistance  to  the 
SSA.  For  all  acquisitions,  the  SSA  is  the  individual  responsible  for  ensuring  the  proper  and  efficient 
conduct  of  the  source  selection  process,  and  for  making  the  final  selection  decision.  While  it's  next  to 
impossible  to  pinpoint  the  exact  number  of  hours  a  source  selection  team  member  will  spend  performing 
his  specific  duties,  it's  important  for  each  individual  on  the  team  to  know  the  schedule  of  events 
contained  in  the  source  selection  plan,  and  how  the  performance  of  their  individual  responsibilities  can 
impact  the  schedule. 

(2)  At  ASC,  a  valuable  resource  for  the  project  team  to  consult  is  the  Source  Selection 
Support  Program  Office.  ASC/CYX,  located  in  Area  B.  Building  125,  provides  project  teams  with 
automated  RFP  preparation  tools,  atong  with  connections  to  WANG,  VAX,  and  IBM  mainframes, 
presentation  graphic  systems,  and  high  speed  printers.  ASC/CYX  also  provides  advisors,  facilitators, 
and  trainers  to  assist  the  source  selection  team  throughout  the  entire  source  selection  process. 

d.  LESSONS  LEARNED:  ASC/CYX  has  documented  numerous  lessons  learned  into  a  text 
entitled,  ASC  Request  for  Proposal  and  Source  Selection  Lessons  Learned.  While  it’s  impossible  to 
address  all  those  lessons  in  this  data  sheet,  a  sample  of  some  lessons  learned  are  provided  below  for 
consideration  by  the  project  team.  If  the  project  team  would  like  a  more  comprehensive  data  bank  of 
lessons  learned,  contact  ASC/CYX  for  a  copy  of  the  text. 
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(1)  Problem  ErKOuntered:  Multiple  reviewers  of  related  source  selection  documents 
such  as  the  Acquisition  Plan,  Source  Selection  Plan,  Evaluation  Guides,  etc.,  led  to  numerous  revisions 
of  documents  due  to  conflicting  recommendations  needing  to  be  resolved.  The  reviewers  often  did  not 
have  recommended  changes  prepared  for  the  documents  in  question,  and  therefore,  were  unable  to 
meet  suspenses.  Poor  planning  and  organization  on  the  part  of  the  reviewers  resulted  in  slippages  to  the 
source  s^ection  scfiedule. 


Lesson  Learned;  While  it  is  necessary  to  have  the  various  functionals 
represented  in  the  review  and  coordination  process  of  source  selection  documents,  it  is  also  necessary  to 
have  solid  up-front  planning  and  review/coordination  ground  rules  established.  All 
reviewers/coordinators  should  be  advised  of  the  ground  rules,  responsibilities,  and  suspenses  associated 
with  the  source  selection  to  ensure  a  more  efficient,  streamlined  process  occurs.  Prior  to  the  final 
preparation  of  the  documents,  the  reviewers  shoukt  meet  to  discuss  any  clarifications/justifications 
needed  so  the  final  documents  prepared  represent  the  coordinated  position  of  all  functionals  involved  in 
the  process. 


(2)  Problem  Er.:x>untered:  Evaluation  standards  usually  only  address  a  specific  technical 
aspect  to  be  scored.  However,  it  is  common  for  the  performance  of  systems/subsystems  to  be 
interrelated,  and  that  any  strengths,  weaknesses,  and  risks  identified  in  one  evaluation  area  may  have 
significant  impacts  on  other  evaluation  areas.  Since  evaluation  team  members  are  usually  assigned  only 
a  specific  area  to  evaluate,  inconsistencies  tend  to  occur  when  interrelated  systems/subsystems  are 
evaluated  by  different  team  members.  The  inconsistencies  cited  from  the  evaluation  of  the  different 
areas  must  be  resolved  prior  to  preparation  of  final  siipport  documentation,  and  this  contributes  to 
additional  time  needed  by  reviewers  to  coordinate  their  efforts. 

Lesson  Learned;  When  evaluation  standards  are  written  for  an 
acquisition,  it's  important  to  address  the  possible  impacts  the  related  systems/subsystems  have  to  one 
another  If  evaluators  understand  the  basic  relationships  of  the  systems  and  how  they  should  be 
reviewed  against  the  standards,  the  evaluators  will  spend  less  time  resolving  discrepancies  and 
inconsistencies  in  tfieir  write-ups. 

(3)  Problem  Encountered;  During  an  evaluation  of  proposals  some  clarification  requests 
(CRs)  to  the  offerors  were  reworded  without  the  coordination  of  the  originator  of  the  CR.  The  rewording 
of  the  clarification  requests  resulted  in  responses  from  offerors  that  failed  to  answer  the  originator's 
questions,  and  in  turn,  resulted  in  unnecessary  discussions  during  the  government-offeror  discussion 
period.  Also,  there  have  been  instances  where  clarification  requests  were  prepared  and  submitted  by 
technical  team  members  outside  their  area  of  responsibility.  When  the  CR  responses  were  received,  the 
team  member  actually  responsible  for  the  evaluation  area  in  question  could  not  relate  to  the  response 
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Lesson  Learned;  The  coordination  of  the  originator  of  a  source  selection 
document  should  occur  prior  to  rewording  any  statements  that  may  change  the  original  intent  of  a 
statement.  By  receiving  the  coordination  of  the  originator,  the  government  will  generate  accurate 
requests  for  information,  and  receive  meaningful  responses  in  return. 

e.  BEST  PRACTICES: 

(1)  The  project  team  should  contact  the  Source  Selection  Support  Office,  ASC/CYX, 
early  in  the  procurement  process  in  order  to  gain  the  benefits  of  CYX  expertise  in  the  source  selection 
process.  ASC/CYX  is  responsible  for  managing  the  source  selection  process  within  the  Aeronautical 
Systems  Center,  along  with  providing  assistance  and  training  to  project  teams.  ASC/CYX  is  comprised 
of  representatives  from  each  of  the  functionals  involved  in  the  acquisition  process,  and  these  individuals 
are  equipped  to  provide  a  wealth  of  information  to  project  teams.  ASC/CYX  provides  training  to  project 
teams  gearing  up  for  request  for  proposal  development  and  source  selection,  along  with  the  related 
activities  and  requirements  of  each.  The  training  begins  early  in  the  acquisition  cycle,  and  progresses  in 
stages  as  the  request  for  proposal  is  developed  and  source  selection  occurs.  ASC/CYX  tailors  the 
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training  to  meet  the  specific  needs  of  each  individual  project  team  by  focusing  on  the  peculiarities  of  the 
acquisition.  ASC/CYX  encourages  project  teams  to  use  the  source  selection  facility  in  Area  B,  Building 
125,  because  of  its  unique  capabilities  in  aiding  the  project  team  build  the  request  for  proposal,  prepare 
necessary  briefings  and  related  documents,  and  also  conduct  the  evaluation  of  proposals  in  one  central 
location.  The  source  selection  fcK:ility  provides  project  teams  an  environment  free  from  the  intemjptions 
that  occur  in  a  normal  office  environment  so  all  their  efforts  are  concentrated  on  the  source  selection  and 
its  successful  completion.  Also,  because  of  the  need  to  ensure  confidentiality  of  source  selection 
information,  it's  imperative  to  conduct  the  source  selection  in  a  secure  environment--the  source  selection 
facility  in  Building  125  provides  such  an  environment 

(2)  It  is  also  recommended  that  ASC/CYX  be  contacted  to  ensure  the  project 
team  is  operating  under  the  most  current  guidance  and  regulations  governing  source  selection.  Akmg 
with  informing  project  teams  of  the  latest  guidance  available  for  source  selections,  ASC/CYX  maintains  a 
text  of  lessons  learned  on  past  source  selection  activities.  A  project  team  may  be  able  to  avoid  problems 
in  their  own  source  selection  by  what  they  learn  in  researching  past  projects. 

(3)  During  the  evaluation  of  proposals,  all  evaluators  should  prepare  detailed, 
written  narratives  as  soon  as  a  strong  or  weak  point  is  cited  in  the  proposal.  Poorly  documented 
narratives  can  lead  to  the  need  to  reevaluate  proposals,  and  thus  result  ikt  a  slippage  to  the  source 
selection  schedule. 


(4)  Try  not  to  have  to  issue  a  second  request  for  BAFO.  It  requires  special 
approval,  and  makes  it  kMk  as  though  the  government  is  trying  to  ’’auction"  with  offerors. 

(5)  Have  the  source  selection  team  and  evaluators  assigned  full-time.  It  will 
shorten  the  source  selection  cycle,  and  maintain  continuity. 

(6)  The  source  selection  standards  should  be  written  before  the  RFP  is  released. 
Writing  standards  during  the  proposal  preparation  period  could  result  in  an  amendment  to  the  RFP 
forcing  an  extension  of  the  proposal  due  date. 

f.  TRAPS:  Failure  on  the  part  of  the  project  team  to  know  what's  contained  in  the  regulations 
governing  source  selection  will  impact  the  completion  of  the  source  selection  process.  Since  the 
regulations  set-out  the  types  of  documents  required,  the  various  levels  of  reviews  required,  and  the 
responsibilities  of  members  in  the  various  source  selection  organizations,  it's  important  for  all  members 
of  the  project  team  to  be  familiar  with  the  source  selection  regulations. 
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1.  ELEMENT:  D71 ,  TBS  1. 2.5.4  7  (IFC  93-3) 

2.  ELEMENT  TITLE:  Prepare  Milestone  I  Program  Cost  Estimate 

3.  ELEMENT  OWNER:  Office  of  the  Secretary  of  Defense  Cost  Analysis  Irr^ovement  Group  (OSD 
CAIG)  -  ACAT I  D;  Air  Force  Cost  Analysis  Improvement  Group  (AFCAIG)  -  ACAT  I  C.  II,  III,  &  IV. 

4.  ELEMENT  STAKEHOLOER(S):  Hq  USAF,  Operating  Command,  Project  Team,  ASC/FM/AL. 

5.  REQUIREMENT:  DoDI  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 ,  Part  II,  Section  A,  paragraph  2C;  Section  C,  Attach  1.  A  Program  Cost  Estimate  must  be  generated 
to  support  MHestone  I  and  an  updated  estimate  must  be  documented  for  each  subsequent  Milestone 
Review.  This  requirement  for  a  documented  program  cost  analysis  of  life  cycle  costs  applies  to  all  ACAT 
levels. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  The  purpose  of  this  activity  is  to  develop  a  program  cost  estimate  and 
documentation  for  the  program  alternative  that  will  be  recommended  for  approval  at  the  Milestone  I 
Decision  Review. 

b.  Objective;  The  objective  is  to  identify  and  quantify  program  resource  requirements  to  support 
the  decision  process,  and  to  develop  the  baseline  for  the  resource  requirements  to  be  included  in  the  Air 
Force  Program  Objective  Memorandum.  (The  Milestone  Decision  Authority  (MDA)  should  direct  that  this 
estimate  be  irKX>rporated  into  the  Air  Force  financial  plan  upon  approval  to  proceed.)  It  must  be  noted 
that  the  efforts  discussed  here  represent  only  those  to  formally  estimate  and  document  the  preferred 
option.  If  analyses  are  required  for  other  alternatives,  program  management  and  the  estimators  must 
assess  the  additional  time  and  resource  requirements  based  on  the  scope  and  complexity  of  the 
alternative  estimates. 

7.  DESCRIPTION:  The  cost  estimate  should  include  all  program  life  cycle  costs;  development, 
production,  operating  and  support,  and  disposal.  Since  the  estimate  will  be  provided  to  support  the 
Milestone  I  decision  to  initiate  the  Demonstratic.  lA/alidation  phase,  the  estimate  should  quantify 
the  activities  for  the  Dem/Val  phase  as  discretely  and  accurately  as  possible,  so  any  necessary 
adjustments  can  be  made  in  near-term  funding  levels.  The  subsequent  phases  may  be  estimated 
at  higher  levels,  based  on  the  best  information  available.  The  development  of  the  Program  Cost 
Estimate  consists  of  planning  and  executing  five  major  activities  which  are  summarized  below. 

The  reader  will  find  a  rrrore  detailed  description  of  these  tasks  in  Chapter  3  of  Vol.  1  of  the 
referenced  AFSC  Cost  Estimating  Handbook.  In  addition,  more  detail  is  provided  in  other  chapters 
of  the  handbook  as  noted  below; 

a.  Defining  the  estimate  -  this  effort  consists  of  defining  the  program  to  be  estimated, 
determining  the  scope  of  the  estimate,  assembling  the  estimating  team  and  assigning  responsibilities, 
and  defining  estimate  groundrules,  assumptions,  and  constraints.  This  should  be  documented  in  the 
estimate  plan,  and  approved  by  the  Project  Manager.  The  estimate  plan  should  contain  a  schedule  for 
the  estimating  activities  based  on  the  estimated  time  required  to  accomplish  the  following  estimating 
tasks.  The  time  required  for  each  of  the  activities  can  be  expected  to  vary  for  every  estimate,  depending 
on  the  size  and  experience  level  of  the  team,  prior  research  and  estimating  efforts  for  the  program,  etc. 
Specific  sources  of  information  which  should  help  define  the  program  to  be  estimated  are  contained  in 
Key  Inputs  (Section  9.a.),  which  follows  (Chapter  4). 

b.  Research  -  the  cost  analysts  perform  initial  research  to  determine  appropriate  estimating 
methodologies,  and  perform  data  collection  to  determine  if  information  can  be  obtained  to  support  the 
selected  estimating  approach(es)  (Chapter  5). 


4r 


•  • 


■ • t ^ •  • 


D-565 


c.  Develop  the  estimating  approach  -  the  preliminary  estimating  methods  are  selected,  and  any 
estimating  tools  are  designed  or  updated,  as  appropriate  (Chapter  6). 

d.  Perform  estimate  and  crosschecks  -  the  analysts  generate  the  detailed  estimates  aixf  verify 
the  results  with  any  appropriate  crosschecks  to  ensure  the  results  are  logical,  reasorud>le,  and  complete. 
(Note;  An  estimate  doojmented  to  support  either  a  milestone  review  or  a  budget  submission  must  reflect 
a  ’point  estimate'.  However,  if  possible,  the  estimators  should  provide  estimate  ranges  to  the  decision 
makers  to  aid  in  the  estimate  review  and  approval  process)  Ch^ter  4,  paragraph  4.5.3). 

e.  Documentation  and  approval  -  the  estimate  must  be  documented  arxf  provided  to 
project  management  for  approval.  This  process  usually  involves  presentation  of  the  estimate  to 
the  senior  program  and  functional  managers  assigned  to  the  projM.  After  hitemal  approval,  the 
estimate  should  be  provided  to  the  Operating  Command  for  review  and  approval.  When  this  is 
completed,  the  estimate  should  be  considered  the  formally  approved  Program  Cost  Estimate  for 
the  Milestone  decision  review,  and  should  be  the  basis  for  all  program  estimate  'what  its*  arvl 
budget  submissions  until  superseded  by  another  formal  program  estimate.  The  reader  should  refer 
to  Chapter  22,  of  the  referenced  AFMC  Cost  Estimating  Handbook,  or  ASDR  173-1  for  more 
detailed  information  on  ASC  estimate  documentation  requirements. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance: 

(1)  If  this  estimating  activity  is  not  already  underway,  IT  MUST  BE  INITIATED  as  soon 
as  the  Milestone  I  Decision  Review  is  scheduled,  so  the  Milestone  estimating  requirements  can  be 
satisfied  with  quality  products  in  time  to  support  all  required  reviews.  Further,  the  estimate  content 
should  be  based  on  the  recommended  program  option  (C25)  selected  from  the  Cost  And  Operational 
Effectiveness  Analysis  (COEA).  However,  while  this  estimate  must  be  based  on  the  program  to  be 
recommerKfed  at  the  Milestone  review,  there  may  be  a  requirement  for  the  generation  of  alternate 
estimates  or  excursions  to  support  the  decision  process.  To  ensure  that  these  and  all  other  requirements 
are  satisfied,  the  Project  Manager  must  keep  in  close  contact  with  the  responsible  personnel  in  the 
Operating  Command,  assumed  here  to  be  the  Concept  Action  Group  (Cl  6).  The  CAG  should  be 
responsible  for  working  issues  with  USAF  and  OSD  to  ensure  that  all  issues  are  resolved. 

(2)  If  any  additional  estimates  are  required,  the  additional  effort  for  development  of 
these  estimates  and  any  supporting  documentation,  such  as  the  Cost  Analysis  Requirements  Description 
(CARD),  must  be  included  in  the  planning  for  the  Milestone  review.  Specifically,  for  any  programs  that 
the  OSD  CAIG  will  review,  the  CAIG  Chair  coordinates  on  the  description  of  the  alternatives,  the  scope 
of  the  estimates  to  be  made,  and  the  assumptions  needed  for  developing  the  cost  estimates.  Finally, 
this  information  must  also  be  documented  in  the  CARD  format  (D72).  For  non-OSD  CAIG  program 
reviews,  coordination  should  be  performed  to  ensure  that  the  MDA  and  the  organization  responsible  for 
reviewing  the  estimates  are  provided  all  information  that  is  expected,  or  the  Milestone  approval  may  be 
delayed. 

b.  Exit;  The  estimate  should  be  reviewed  and  approved  by  both  the  Project  Manager  and  the 
Concept  Action  Group  (CAG)  in  the  Operating  Command  prior  to  submission  into  the  Milestone  Decision 
review  process.  For  programs  which  will  undergo  an  Air  Force  CAIG  review,  the  following  events  are 
mandated  by  the  draft  AF  Sup.  1  (to  DoDI  5000.2)  to  occur  no  later  than  the  schedule  dates  (in  calerKfar 
days)  which  follow.  (Note:  These  requirements  also  apply  to  the  Component  Cost  Analysis  (CCA)  team, 
and  any  meetings  or  reviews  will  address  both  estimates.) 
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DAB  Program  Requiramenis 

Days  Prior  to/ 

Air  Force  Review 

Draft  project  office  estimate  submitted  to  AFCAIG  55  /Committee 

Project  Office  presents  estimate  for  SAF/FMC  *shirt  sleeve'  review  55  /  DAB 

Prefect  Office  presents  estimate  to  AF  CAIG  51  /  DAB 

Final  project  office  estimate  submitted  to  AFCAIG  28  /  DAB 

Air  Force  Mileatorte  or  Program  Review  Requirements 

Days  Prior  to 
Air  Force  Review 


Draft  project  office  estimate  submitted  to  AFCAIG  24 

Project  Office  presents  estimate  for  SAF/FMC  'shirt  sleeve'  review  18 

Final  project  office  estimate  submitted  to  AFCAIG  14 

Project  Office  presents  estimate  to  AF  CAIG  1 1 


These  activities  only  reflect  the  program  office  responsibilities  relating  to  the  review  and  approval  of  the 
Program  Cost  Estimate.  Numerous  other  events  and  activities  will  be  required  to  support  AFSARC/DAB 
Program  Reviews.  For  other  programs,  the  estimate  must  be  generated  to  support  [banning  schedule 
directed  by  the  CAG  and/or  the  MDA.  It  is  imperative  that  the  program  office  be  proactive  and 
coordinate  with  the  scheduling  authority  to  ensure  that  reasonable  and  executable  schedule  dates  are 
developed. 

9.  KEY  INPUTS  AND  OUTPUTS: 
a.  Inputs; 

(1 )  At  this  stage  of  the  project,  usually  only  limited  technical  and  programmatic 
information  is  available,  but  to  derive  a  comprehensive  estimate  of  total  program  costs,  the  proj^t  team 
must  agree  on  a  baseline  program  content  which  can  be  estimated.  DoDM  5000.2M  requires  this 
description  of  program  content  to  be  documented  in  a  specific  format,  the  Cost  Analysis  Requirements 
Description  (CARD).  The  program  information  must  be  consistent  with  CAG  direction,  and  the 
assumptions  and  data  utilized  in  the  COEA  analysis.  The  program  information  should  include  system 
description  (to  the  extent  possible),  development  and  production  schedules,  quantities,  and  acquisition 
and  support  strategies.  The  source  of  this  information  should  be  the  project  team  members 
(errgineering,  manufacturing,  contracts,  logistics,  test,  and  management)  and  Operating  Command 
personnel.  In  addition  to  providing  detailed  information  on  their  functional  areas,  these  experts  will  need 
to  support  the  cost  estimators  by  identifying  analogous  programs,  and  aiding  in  the  devek^ment  and 
justification  of  the  selected  estimating  relationships.  It  is  irr^rative  that  senior  functional  personnel, 
knowledgeable  in  both  program  acquisition,  and  the  specific  program,  be  involved  in  this  program 
planrvng  and  estimating  support. 

(2)  The  results  of  this  program  definition  effort  should  be  well  documented  in  the  CARD, 
and  this  document  must  be  the  source  of  the  estimate  content  arxJ  assumptions.  This  information  should 
be  documented  as  clearly  as  possible,  as  annual  updates  of  the  CARD  are  required,  and  any  revisions 
must  be  tracked.  (Note;  This  cannot  be  overemphasized,  since  alt  levels  of  Air  Force  management  will 
require  tracking  between  program  cost  estimates  provided  to  them.)  Although  a  CARD  is  only  required 
documentation  for  ACAT  I  &  II  program  reviews,  developing  a  CARD  should  provide  valuable  insight  into 
areas  that  warrant  further  analysis  for  any  program.  Moreover,  even  when  not  mandatory,  the 
development  of  a  CARD  should  improve  both  the  quality  and  credibility  of  the  cost  estimate. 

(3)  If  contractor  cost  proposal  information  (B70)  is  available  for  the 
Demonstration/Validation  phase,  this  information  should  be  evaluated  and  incorporated  into  the  estimate 
as  appropriate.  In  addition,  the  Component  Cost  Analysis  team  (B21 )  may  find  information  during  it 
anatysis  vrhich  the  project  team  determines  should  be  incorporated  into  their  estimate.  This  may  also 
prove  to  be  a  valuable  input  to  the  Milestone  I  estimate,  even  if  received  late  in  the  analysis  process. 
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b.  Outputs:  The  results  of  the  above  cost  analysis  effort  should  be  documented  as  the  Program 
Cost  Estimate  for  the  Milestone  I  review,  and  approved  by  ^  Project  Manager  and  archived  in  the 
project  database.  The  documentation  must  include  ail  groundrules  and  assumptions  and  programmatic 
information  necessary  to  replicate  the  estimate  arxi  fully  support  cost  relationships  utilized.  At  ASC,  the 
documentation  must  be  accomplished  in  accordance  w^h  /^OR  173-1.  if  the  estimate  win  be  reviewed 
by  the  AF  or  OSD  CAIGs,  the  documentation  should  be  gerterated  in  accordance  with  the  referenced 
"Cost  Estwnating  Documentation  Checklist"  and  'OPERATING  AND  SUPPORT  COST'  ESTIMATING 
GUIDE,  and  the  draft  documentation  must  be  provided  to  the  AFCAIG  (and  the  CCA  team.  B21 )  no  later 
than  55  days  prior  to  the  planned  Defense  Acquisition  Board  Committee  review.  For  Air  Force  Milestone 
Program  reviews,  the  estimate  must  be  delivered  no  later  than  24  days  prior  to  the  Air  Force  Review. 
This  is  essential,  since  the  estimate  is  a  critical  input  to  both  the  Independent  Cost  Estimate  activity,  arxf 
the  CAIG(s)  review  and  analysis.  Failure  to  satisfy  these  requirements  could  result  in  a  slip  in  the 
Milestone  I  review  process.  If  a  source  selection  is  being  conducted  (D70).  the  contractors'  cost  proposal 
information  should  be  valuable  information  for  this  estimate.  Further,  some  elemerrts  of  this  estimate 
may  need  to  be  incorporated  into  the  source  selection  analysis  to  develop  a  complete  estimate  of 
program  costs. 

10.  KEY  REFERENCES: 

a.  DODD  5000.4,  OSD  Cost  Analysis  Improvement  Group,  24  Nov  92  -  Chapter  1 
provides  guidance  on  CARD  preparation,  and  Chapter  2  addresses  the  requirements  for  cost 
analysis  presentations  to  the  OSD  CAIG. 

b.  AFR  173-1 ,  The  Air  Force  Cost  Analysis  Program,  3  Oct  80  -  Establishes  the  Air  Force  Cost 
Analysis  Program,  specifies  objectives  and  functions,  and  assigns  responsibilities. 

c.  AFR  173-11,  Independent  Cost  Analysis  Program,  7  Oct  86  -  Identifies  requirements  for 
Independent  Cost  Analysis  and  Program  Office  Estimates. 

d.  AF  Instruction  10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance  and 
Procedures,  16  Feb  93,  paragraphs  1 .3.10, 1 .4,  Attachments  1 . 2,  and  5  -  Provides  guidance  on 
the  CAG  and  COEA. 

e.  AF  Sup.  1/DoDI  5000.2,  Aug  92  (DRAFT).  Part  10A  -  Air  Force  cost  estimating 

requirements. 

f.  DoD  5000 .4-M,  Cost  Analysis  Guidance  and  Procedures,  Dec  92,  Chapter  1  -  CARD 
preparation . 

g.  ASDR  1 73-1 ,  Aeronautical  Systems  Division  Cost  Analysis  Program,  17  Jan  89  -  defines  the 
cost  estimating  responsibilities  and  requirements  for  project/program  offices  at  ASC,  and  provides 
comprehensive  guidance  on  estimating  documentation. 

11.  IMPLEMENTATION  TOOLS:  ASC/FM  can  provide  information  on  the  following  cost  analysis  aids 
and  tools: 

a.  The  AFSC  Cost  Estimating  Handbook.  Vol  I  (undated)  -  estimating  and  documentation 
information. 

b.  The  AFSC  Financial  Management  HarKfcook.  Nov  92  update  -  financial  information. 

c.  ASC/FM  Cost  Workstation  -  a  computer  automation  aid  and  application  tool. 

d.  The  ASC  Cost  Data  Center  -  historical  cost  data,  cost  models,  and  other  cost  related 
materials  and  references. 
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e.  AFMC  Cost  Estimatinn  Manrihnnk  Vol.  II.  Aeronautical.  21  Sept  92  -  estimating  and 
documentation  information. 

f.  OSD/PA&E  letter  ’Policy  for  Operations  of  the  Cost  Analysis  Improvement  Group,'  7  Apr  93. 

g.  The  following  should  be  referred  to  for  documentation  recHJirements; 

1 .  SAF/FM  ’Cost  Estimating  Documentation  Checklist’,  16  Nov  92 

2.  OSD  CAIG  "OPERATING  AND  SUPPORT  COST  ESTIMATING  GUIDE.’ 

May  92. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  time  required  to  perform  and  document  an  estimate  must  be  planrted 
based  on  the  specific  conditions  and  methodologies  chosen.  The  time  can  be  expected  to  vary  for  every 
estimate  depeiiding  on  the  program  complexity,  data  availability,  and  the  size  and  experience  level  of 
the  estimating  team.  Early  in  the  program  life  cycle,  estimating  activities  are  typically  based  on 
parametric  analysis  arxl  should  take  2  to  4  months.  Again,  this  cani  be  considered  firm;  the  time 
required  to  perform  and  document  an  estimate  must  be  planned  based  on  the  specific  conditions  and 
methodologies  chosen. 

b.  CONSTRAINTS:  The  greatest  limitations  in  the  performance  of  the  estimate  are  lack  of 
program  definition,  and  the  lack  of  relatable  historical  cost  information  element.  If  there  are  limited 
personnel  to  accomplish  the  analysis  in  time  to  meet  the  required  schedule,  support  should  be  requested 
from  staff  home  offices  or  the  Program  Development  SPO  (ASC/YX). 

c.  RESOURCES:  The  estimate  is  usually  performed  by  one  or  two  full  time  cost  estimators  in 
the  project  office,  plus  possibly  two  to  four  staff  analysts  if  the  estimate  is  new,  or  represents  a  major 
woiklo^.  Operating  and  Support  cost  estimating  support  from  ASC/AL  may  also  be  required  if  the 
project  office  does  not  have  the  in-house  capability  to  perform  this  analysis.  Engineering,  logistics,  test, 
and  program  management  personnel  should  be  formally  assigned  to  the  estimating  team,  even  if 
dedicated  only  part  time,  and  they  can  be  expected  to  each  need  to  provide  a  minimum  of  80  hours  for 
technical  support,  if  the  estimate  is  new.  Computer  assets  are  considered  a  necessity  for  both 
computation  and  documentation. 

d.  LESSONS  LEARNED: 

(1)  The  Cost  Staff  (ASC/FMC)  should  be  contacted  to  have  a  staff  cost  analyst  focal 
point  assigned  to  support  the  analysis  effort.  This  analyst  could  be  a  valuable  resource  by  aiding  in  data 
searches  and  estimating  methodology  selection.  The  analyst  can  also  be  a  valuable  asset  in  supporting 
management  reviews.  Further,  the  cost  staff  may  be  able  to  provide  analysts  to  support  or  perform 
elements  of  the  estimate,  or  personnel  to  perform  schedule  analysis.  It  should  be  expected  that  many 
estimating  variations  and  estimating  excursions  to  the  preferred  program  option  will  be  requested  to 
support  the  decision  making  process;  each  of  these  should  be  ck^mented  and  tracked,  by  both  program 
content  and  estimate  results.  Failure  to  do  so  can  result  in  significant  rework  and  loss  of  credibility.  If 
alternative  programs  must  be  estimated  that  have  content  significantly  different  from  the  preferred 
program  option,  the  prt^ram  office  should  consider  requesting  the  Cost  Staff  to  take  responsibility  for  the 
generation  of  these  estimates. 

(2)  The  project  office  must  maintain  a  complete  file  of  estimates  that  have  been  used  in 
the  decision  process,  so  all  rationale  and  considerations  are  available  for  review.  Further, 
comprehensive  tracks  between  formal  estimates  should  be  performed  and  documented. 
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e.  BEST  PRACTICES:  The  cost  analyst  should  develop  a  comprehensive  estimate  plan  which 
defines  program  content,  describes  the  estimating  approach  and  the  estimate  schedule,  identifies 
estimate  team  members  and  assigns  resportsibilities,  and  identifies  estimate  groundrules  and 
assumptions.  The  management  approval  of  this  plan  should  ensure  the  commitment  of  necessary 
resources,  and  baseline  the  program  to  be  estimated.  Lack  of  a  comprehensive  plan  may  result  in 
unnecessary  perturbations,  rework,  and  schedule  slips.  The  estimate  plan  should  be  coo^nated  wtth 
the  CAG  arid  the  representative  of  the  MDA  to  ensure  all  requirements  are  fully  identified,  defined,  and 
satisfied. 

f.  TRAPS: 

(1)  It  is  imperative  mat  cost  analysts  identify  methodologies  and  data  requirements  as 
soon  as  possible  so  these  needs  can  be  made  known.  If  this  information  is  not  available,  work-arounds 
must  be  made  as  soon  as  possible  to  maintain  the  estimating  schedule  and  support  the  Milestone 
Decision  process.  Also,  it  is  essential  that  the  estimating  and  functional  team  members  be  carefully 
selected,  so  that  the  best  possible  analysis  can  be  performed  at  this  time,  and  a  sound  financial  baseline 
can  be  established  to  support  planning  activities. 

(2)  The  estimate  discussed  above  had  its  genesis  in  the  COEA  analysis,  and  during  the 
milestone  reviews,  the  estimate  will  be  compared  to  the  estimates  for  the  other  COEA  alternatives.  Due 
to  this,  IT  IS  ESSENTIAL  that  any  changes  to  the  program  content,  assumptbns.  or  estimate  results  be 
incorporated  into  the  COEA.  Failure  to  do  this,  may  result  in  insufficient  or  contradictory  information 
provided  to  the  Milestone  decision  makers,  and  a  possible  delay  in  program  approval.  Further,  if  a 
source  selection  estimate  is  beirtg  generated,  the  cost  analyst  must  ensure  that  it  is  consistent  with  the 
estimate  generated  here  for  the  Milestone  I  Review. 
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1.  ELEMENT:  D72,  TBS  1 .2.4.5  6  (IFC93-3) 

2.  ELEMENT  TITLE:  Update  Cost  Analysis  Requirements  Oescriplion  (CARD) 

3.  ELEMENT  OWNER(S):  OSD/PA&E 

4.  ELEMENT  STAKEHOLOER(S):  OSD  CAIG,  AF  CAIG.  AFCAA.  Product  Division  StaN,  Project 
Office.  Anyone  involved  in  preparing  or  reviewirtg  a  cost  estimate. 

5.  REQUIREMENT:  DODI  5000.2,  Defense  Acquisition  Management  Policies  arxf  Procedures,  Change 
1 , 26  Feb  93,  Part  1 1 ,  Section  C,  Attachment  1  indicates  a  CARD  is  required  no  later  than  the  Milestone 
Planning  Meeting. 

DOD  5000.4-M  Acquisition  Policy  93M-012,  28  Jun  93,  Provides  information  on  developing  the  CARD. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose:  Update  the  technical  and  programmatic  description  of  selected  altemative(s)  used 
by  the  cost  analysts  estimating  the  cost  of  the  altemative(s). 

b.  Objectives: 

(1)  Provide  the  program  office  cost  estimating  and  the  component  cost  analysis  teams 
with  a  common  basis  for  their  project  cost  estimates. 

(2'  Describe  the  salient  features  of  the  program  and  of  the  system  to  be  estimated. 

(3)  Facilitate  the  identification  of  any  area  or  issue  that  could  have  a  significant  effect  on 

life-cycle  costs. 

7.  DESCRIPTION: 

a.  A  CARD  should  be  regarded  as  a  "living*  document  that  is  updated  as  technical  or 
programmatic  changes  occur.  There  are  several  reasons  for  updating  the  draft  CARD  (D52)  at  this  time: 

(1 )  The  preferred  concepts  have  been  further  defined  (D37b), 

(2)  Phase  I  plans  are  being  developed/updated  (D57,  D58.  D59.  D60,  D61 ,  D66,  D67, 

D68), 

(3)  A  project  estimate  is  required  to  support  the  budget  process,  and 

(4)  The  project  has  been  scheduled  for  a  Milestone  I  review  (A23,  B19). 

Whenever  the  CARD  is  updated  the  changes  need  to  be  identified,  so  the  cost  analyst  just  has  to  update 
the  affected  portion(s)  of  the  estimate.  Chapter  1 1  of  the  CARD  is  used  to  track  these  changes. 

b.  DOD  5000.4-M  provides  guidelines  for  the  preparation  and  maintenance  of  a  CARD.  The 
following  paragraphs  summarize  some  of  the  key  procedures  for  preparing  CARDS  and  submitting  them 
as  part  of  a  Milestone  (MS)  review  package. 

(1) .  A  CARD  is  prepared  by  the  project  office  (or  an  organization  specified  by  the 
sponsoring  DoD  Component  if  a  program  office  does  not  exist)  for  each  alternative  considered  in  the 
cost  and  operational  effectiveness  analysis  (COEA).  When  appropriate,  CARDs  can  be  prejiared  as 
excursions  to  the  preferred  altemative(s)  or  one  of  the  other  alternatives.  CARDs  are  approved  by  the 
Program  Executive  Officer  (PEO)  or  the  Designated  Acquisition  Commander  (DAC) . 

(2) .  The  CARD  is  provided  to  the  teams  preparing  the  Program  Office  Estimate  (POE) 
and  Compo^nt  Cost  Analysis  (CCA)  estimates  and  is  included  as  a  separate  section  of  the 
documentation  for  those  estimates.  For  acquisition  category  (ACAT)  I  projects,  an  updated  CARD  is 
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provided  in  draft  form  to  the  Office  of  the  Secretary  of  Defense  (OSD)  Cost  Analysis  Improvemen* 

Group  (CAKj)  and  the  Air  Force  CAIG  at  the  planning  meeting  (A23,  DAB  Planning  Meetir>g.  and  B19. 
AFSARC/DAB  Ranning  Meeting)  held  at  least  180  days  before  a  Defense  Acquisition  Board  (DAB) 
review  (A22,  DAB  Review).  A  final  version  of  the  CARD  is  provided  to  the  OSD  CAIG  45  days  prior  to  a 
DAB  Committee  review  (A20,  OSD  Committee  Review).  For  ACAT II  projects,  the  updated  CARD  is 
provided  in  draft  form  to  the  AF  CAIG  at  the  planning  meeting  (B19.  AFSARC/DAB  Plannmg  Meeting) 
and  a  final  version  of  the  CARD  is  provided  to  the  AF  CAIG  prior  to  an  AFSARC  review  (B24,  AFSARC 
Meeting). 

c.  The  level  of  technical  and  programmatic  information  about  an  acquis4ion  program  that  may 
be  available  for  incorporation  into  the  CARD  will  vary  significarMly  depeixfing  upon  the  maturity  of  the 
program.  Understandably,  programs  in  Phase  0  are  less  defirred.  Accordingly,  the  CARD  for  a  Pre- 
Milestone  I  program  may  present  the  information  in  terms  of  ranges  of  potential  outcomes.  If  a  source  is 
referenced  in  the  CARD,  it  should  be  included  as  an  attachment  to  the  CARD. 

d.  Since  the  CARD  is  one  of  the  documents  required  for  Milestone  review,  it  should  be  included 
in  the  milestone  documentation  review  cycle.  It  will  also  need  to  be  reviewed  by  the  following  offices: 
the  Using  Command  point  of  contact,  ASC/FM,  AFMC/FMC,  AF  CAIG,  arxl  the  OSD  sponsoring 
committee.  These  reviews  are  normally  accornplished  at  the  same  time  the  POE  is  reviewed  and  in 
preparation  for  the  ICE.  The  Program  Executive  Officer  (PEO)  approves  the  CARD  for  submission  to 
the  OSD  CAIG  and  the  DAB. 

e.  The  CARD  will  be  “frozen"  at  some  point  during  the  Milestone  review  process  so  both  the 
POE  and  CCA  can  be  based  on  the  same  description. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  There  are  several  reasons  the  CARD  may  need  to  be  updated.  These  include: 

(1)  Decision  has  been  made  to  proceed  to  Milestone  I. 

(2)  Program  office  estimate  is  being  updated. 

(3)  Technical  and/or  programmatic  aspects  of  project  have  changed. 

b.  Exit:  The  cost  analysts  preparing  the  Program  Office  Estimate  (POE)  (D71 )  and  the 
Component  Cost  Analysis  (CCA)  (B23)  are  satisfied  that  the  CARD  is  comprehensive  enough  for  them  to 
conduct  their  cost  estimating  exercises. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  INPUTS; 

(1)  Draft  CARD  (D52) 

(2)  Milestone  0  Program  Management  Directive  (BIO)  --  Identifies  which  alternatives  are 

to  be  studied. 

(3)  COEA  Report  (D48) 

(4)  Technical  and  programmatic  information.  DOD  5000.4  M,  Chapter  1  provides  an 
“Outline  of  CARD  Basic  Structure"  which  defines  what  information  each  paragraph  should  contain.  The 
following  list  identifies  some  of  the  information  the  CARD  should  contain.  It  also  indicates  some  of  the 
documents  that  may  corrtain  the  required  information. 

(a)  System  configuration  (D37B) 

(b)  Mission  Need  Statement  (A8) 

(c)  System  Threat  Analysis  Report  (D50) 

(d)  Relationship  to  other  systems  (D37B) 

(e)  Major  factors  influencing  cost  (D37B) 

(f)  Technical  description  of  the  hardware  and  software  (D37B) 

(g)  Human  characteristics  of  the  system  (D37B) 


(h)  Preliminary  Irttegrated  Manpower.  Personn^  and  Comprehertsive  Training 
and  Safety  (IMPACTS)  Program  Plan  (P-IPP)  (C1 1 ) 

(i)  Project  Manager's  Risk  Assessment/Abatement  Plan  (055) 

(j)  Unit  Manpower  Document  (022) 

(k)  Integrated  Logistics  Support  Plan  (023) 

(l)  Total  System  Training  Ran  (60) 

(m)  Quantity  Requirements  (D37B) 

(n)  System  Manpower  Requiremer^s  (Cl  1) 

(o)  System  Activity  Rates  (D37B) 

(p)  System  Milestone  Schedule  (055) 

(q)  A^uisition  Plan  and/or  Strategy  (058) 

(r)  System  Development  Plan  (D37B) 

(s)  TEMP  (054) 

(t)  Facilities  requirements  (D37B) 

(u)  Environmental  Impact  Analysis  (057) 

b.  OUTPUTS:  The  CARD.  OoO  5000.4-M,  Chapter  1 ,  provides  a  detailed  description  of  what  is 
required  in  each  section. 

10.  KEY  REFERENCES: 

a.  DoDO  5000.2-M,  Defense  Acquisition  Management  Documentation  and  Reports,  Feb  91 . 

Part  1 5  requires  development  of  the  CARO. 

b.  0001  5000.4,  OSD  Cost  Analysis  Improvement  Group  (CAIG),  24  Nov  92.  Section  0 
outlines  OSD  CAIGs  role  in  using  and  reviewing  the  CARO. 

c.  000  5000.4-M.  Cost  Analysis  Guidance  and  Procedures,  Dec  92.  Chapter  1  provides 
guidelines  for  the  preparation  and  maintenance  of  a  CARD. 

11.  IMPLEMENTATION  TOOLS:  None 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  CARD  is  a  Tiving"  document  which  should  be  updated  whenever  a 
significant  technical  or  programmatic  change  occurs.  As  a  minimum  the  CARD  is  updated  in  preparation 
for  DAB  reviews  and  each  POE  update.  The  updates  should  document  and  track  changes  that  have 
occurred  and  should  incorporate  additional  data  developed  since  the  last  update.  The  length  of  time 
required  to  accomplish  this  update  will  depend  on  how  much  has  changed  since  the  last  update. 

b.  CONSTRAINTS:  Limited  technical/programmatic  detail  prior  to  MS  I .  Much  technical  detail 
is  unavailable  until  after  MS  II. 

c.  RESOURCES:  Approximately  40  hours  each  from  all  of  the  functional  areas.  Again,  this 
deperxis  on  how  much  new  information  is  available  since  the  last  update. 

d.  LESSONS  LEARNED:  It  is  vitally  important  that  the  CARD  be  "frozen”  during  preparation 
for  a  given  milestone  review.  All  documentation  submitted  in  support  of  a  DAB  review  must  speak  to  the 
program  that  is  briefed  to  the  Milestone  Decision  Authority. 

e.  BEST  PRACTICES:  Prior  to  submission  to  the  appropriate  SAF/AQ  office,  the  CARD  should 
be  coordinated  with  the  CCA  team  chief.  This  will  give  the  cost  analysts  the  opportunity  to  contribute  to 
the  CARD  preparation  and  provide  them  with  estimating  information  to  allow  the  earliest  possible  start  of 
the  CCA. 
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f.  TRAPS:  The  cost  analysts  responsible  for  preparing  the  POE  should  review  the  CARO 
before  it  is  submitted  to  the  AF  CAIG.  These  analysts  should  perform  a  quaMy  check  to  ensure  that  the 
CARD  is  complete  and  contains  all  the  information  they  will  need  to  prepare  the  POE. 
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1.  ELEMENT:  D73,  TBS  12.4.6  (IFC  93-3) 

2.  ELEMENT  TITLE:  Update  Database 

3.  ELEMENT  OWIERS:  Operating  Command.  Implementing  Command,  Product  Center  Development 
Planning  Directorate  (XR)  and  Program  Development  SPO  (ASC/YX),  Industry. 

4  ELEMENT  STAKEHOLDERS: 

a.  Implementing  Agencies:  Department  ol  Defense  (DOD),  Secretary  of  the  Air  Force  (SAF), 
Implementing  Command,  Product  Center  XR  and  YX  (ASC). 

b.  Supporting  Agencies:  Air  Force  Intelligence  Support  Agency  (AFISA),  Air  Force  Studies  and 
Analysis  Agency  (AFSAA),  Laboratories,  Industry,  Operating  Commands. 

5.  REQUIREMENT: 

a.  Air  Force  Policy  Directive  (AFPD)  10-6,  Mission  Needs  and  Operational  Requirements,  19 
Jan  93:  This  directive  requires  the  implementation  of  the  DOD  5000  series  documents,  which  in  turn 
requires  the  maintenance  of  database. 

b.  AFPD  37-1 ,  Information  Management:  (On  order,  upon  receiving  document,  the  definition 
will  be  constructed). 

c.  AFPD  63-1 ,  Acquisition  System:  (On  order) 

d.  AFR  55-43,  Management  Operations,  Test  and  Evaluation,  29  Jun  90:  This  regulation 
describes  he  support  document  requirements  and  the  Data  Management  and  Analysis  Plan. 

e.  Department  Of  Defense  Direcfive  (DODD)  5000.1 .  Defense  Acquisition,  23  Feb  91 : 
Establishes  a  disciplined  management  approach  for  acquiring  systems  and  materiel  that  satisfy  the 
operational  user's  needs. 

f.  DODD  8320.1 ,  Data  Administration,  26  Sept  90:  (On  order) 

g.  MIL-STD-1388-1 A,  Logistics  Support  Analysis  (LSA),  1 1  Apr  83:  The  goal  of  this  standard  is 
a  single,  uniform  approach  by  the  Military  Services  for  conducting  activities  necessary  to  cause 
supportability  requirements  to  be  an  integral  part  of  system  requirements  and  design,  with  documentation 
developed  and  maintained. 

h.  MIL-STD-499B,  Systems  Engineering.  Draft:  The  decision  database  may  be  digital,  defined 
by  the  Government  or  left  open  for  contractor  definition. 

i.  MIL-STD-1388-2B,  DOD  Requirements  for  a  Logistics  Support  Analysis  Record,  28  Mar  91 : 
This  standard  is  directed  toward  improving  the  cost  effectiveness  of  the  generation,  maintenance, 
acquisition,  and  use  of  the  technical  data  required  to  support  an  LSA  program. 

j.  MIL-STD-1840A,  Automated  Interchange  of  Technical  Information,  22  Dec  87;  The  purpose 
of  this  standard  is  to  standardize  the  digital  interface  between  organizations  or  systems  exchanging 
digital  forms  of  technical  information  necessary  for  the  logistic  support  of  weapon  systems  throughout 
their  life  cycle. 

6.  PURPOSeOBJECTIVES: 

a.  Purpose:  The  purpose  of  the  data  base  is  to  provide  a  central  location  for  the  collection  and 
storage  of  information/data.  This  information /data  will  support  the  Project  Teams  and  subsequent 


Nov  93 


Systems  Program  Office  in  making  decisions  that  respond  to  external  and  internal  requirements,  (i.e.  the 
^formation  needs  of  milestone  decision  authority). 

b.  Objective:  At  this  point  the  database  is  updated  using  Phase  0  project  activities  planned  since 
the  establishment  of  Project  Database.  D1 5,  and  subsequent  updates  in  D31 ,  044  and  D49. 

7.  DESCRIPTION: 

a.  The  database  is  the  information  used  and  generated  for  integrated  requirements  and 
flowdowns;  interface  constraints  and  configuration  alternatives,  verifications,  decision  criteria,  trade  study 
assessments,  and  any  other  required  documents.  It  includes  physical  and  mathematical  models, 
computer  simulations,  layouts,  and  similar  configuration  documentation  and  technical  data,  as 
appropriate.  To  update  the  database  at  this  time  is  important,  because  this  is  the  final  opportunity  to 
complete  information  on  the  total  program  development  process,  in  particular,  the  activities  related  to 
planning  and  organizing  for  the  program. 

b.  An  operational  database  will  continue  to  use  M)L-STD-1388,  MIL-STD-499B,  MIL-STD- 
1840A,  Computer-Aided  Acquisition  and  Logistics  Support  (CALS),  Contractor  Integrated  Technical 
Information  Senrice  (CITIS),  and  Integrated  Weapon  System  Management  (IWSM).  The  management 
information  system  will  continue  to  provide  tools  for  engineers;  share  program  data  with  analysts, 
contractors,  and  the  customer;  management  overview  of  program  data  and  schedules;  and  a  paperless 
delivery  if  appropriate,  of  required  data.  The  database  at  this  point  will  serve  tor  the  newly  forming 
SPOs  as  the  prime  starting  point  of  information  source.  The  up-to-date  database  will  also  become  the 
new  organization's  information  depository. 

8  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  This  is  a  continuous  activity,  intended  to  be  current  since  established  in  D1 5. 

b.  Exit;  The  Data  Base  will  continually  be  updated  throughout  the  Pre-Milestone  1  process  and 
beyond.  As  the  SPO  will  be  formed,  the  database  will  go  with  the  new  SPO. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs: 

All  documentation  from  Definition  of  Preferred  Concept  Alternatives  (D37B). 

All  documentation  from  Complete  Milestone  I  Documents  and  Plans  (D68). 

Other  approved  pertinent  information  since  Update  Database  (D49). 

b.  Outputs: 

All  above  inputs  are  used  unaltered  as  outputs. 

10.  KEY  REFERENCES:  (In  addition  to  those  listed  in  Requirements,  Paragraph  5) 

a.  Air  Force  Instruction  (AFI)  10-601 ,  Mission  Needs  and  Operational  Requirements  Guidance 
and  Procedures,  16  Feb  93;  Identifies  official  Air  Force  information  required  for  decision  making  and 
historical  purpose  and  develop  a  schedule  of  the  information  life  cycle  to  describe  creation, 
maintenance,  and  disposition  (AFI  37-123,  Management  of  Records). 

b.  AF1 10-602,  Logistics  Support  and  Readiness  Requirements;  (On  order,  upon  receiving 
document,  the  definition  will  be  written). 

c.  AF1 14-303,  Threat  Support,  Acquisition  Process;  (On  order). 

d.  AF1 16-501 .  Control  and  Documentation,  Air  Force  Programs:  (On  order). 

e.  AFI  33-105,  Information  System,  Standard  Programs;  (On  order). 
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1.  AFI 37-1 ,  Information  Management;  (On  order). 

g.  AFI  37-123,  Management  of  Records;  Identifies  the  activities  to  plan,  design,  model, 
synchronize,  standardize  and  control  Air  Force  Corporate  data  at  all  echelor^. 

h.  AFI  37-150.  Data  Administration  and  Standards  Program;  (On  order). 

i.  DOD  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and  Procedures,  23  Feb 
91 ;  Establishes  an  integrated  framework  for  translating  broadly  stated  mission  needs  into  stable, 
affordable  acquisition  programs  that  meet  the  operational  user's  needs  and  can  be  sustained,  given 
projected  resource  constraints. 

j.  DOD  Manual  5000.2M,  Defense  Acquisition  Management  Documentation  and  Reports,  23  Feb 
91 ;  This  Manual  implements  relevant  portions  of  DODD  5000.1  and  DODD  5000.2.  Specific 
responsibilities  pertaining  to  major  areas  are  provided  in  each  individual  section,  as  appropriate. 

k.  Implementing  Command;  Submit  required  acr^isition  program  documents.  (Defense 
Planning  Guide,  Mission  Area  Assessment,  and  Mission  Needs  Analysis,  etc  ). 

l.  MIL-HDBK-59A,  DOD  Computer-Aided  Acr^isition  and  Logistic  Support  (CALS)  Program 
Implementation  Guide;  The  purpose  of  this  military  han{ft>ook  is  to  provide  general  information  and 
detailed  application  guidance  for  contractually  implemerrting  CALS  requirements  in  weapon  system  and 
related  major  equipment  procurements. 

m.  MIL-HDBK-X499-3,  Systems  Engineering/Configuration  Management.  Draft;  The  decision 
database  will  provide  an  audit  trail  from  initially  stated  needs  and  requirements  to  the  current  description 
of  system  products  and  processes. 

n.  Secretary  of  the  Air  Force  (SAF/AAI);  SAF/AAI  will  ensure  compliance  with  DOD  Corporate 
Information  Management  (CIM)  to  allow  sharing  of  data  with  appropriate  DOD  agencies  and  other 
Government  agencies. 

0.  Supporting  Command;  The  Supporting  Command  will  collect  and  process  Integrated  Logistic 
Support  (ILS)  information  in  the  Logistics  Management  Information  System  (LMIS).  Outline  the  actions, 
support,  and  documentation  needed  to  establish  maintenance  requirements  for  on  and  off  equipment 
throughout  the  life  of  the  system.  Identify  data  collection  and  analysis  efforts  that  will  continue  after 
fielding  of  system  equipment. 

p.  Using  /Operating  Command;  The  user  will  ensure  data  and  management  needs  are 
identified.  Integrate  the  Logistics  Support  Analysis  process  with  the  System  Requirements  Analysis 
activity.  Outline  the  actions,  support,  and  documentation  needed  to  establish  maintenance  requirements 
for  on  and  off  equipment  throughout  the  life  of  the  system. 
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11.  IMPLEMENTATION  TOOLS: 

a.  Automated  Data  Processing  (ADP)  is  available  as  Government  Furnished  Property  (GFP).  ^ 

Contact: 


Director  USAMC  Logistic  Support  Activity 
ATTN.:  AMXLC-AL 
Lexington,  KY  4051 1-5101 

606-293-4193  (Mr.  David  Henderson)  • 

b.  Computer-Aided  Acquisition  and  Logistic  Support  (CAlS):  The  repository  of  information  used 
and  generated  at  the  appropriate  level  for  the  acquisition  phase  of  integrated  requirements  and 
flowdowns,  interface  constraints  and  requirements,  functional  and  performance  requirements,  system 
concept,  preliminary  design  and  configuration  alternatives,  details  design,  verifications,  decision  criteria, 
trade  stu^  assessments,  system,  subsystem,  and  functional  capability  assessments,  and  other  required  ^ 

documentation. 


(a)  MIL-HDBK-59A 

(b)  MIL-STD-1840A 

c.  Systems  and  Logistics  Integration  Capability  (SLIC):  This  is  a  state-of-the-art,  DOD  Type  III  ^ 

validated,  micro  computer  based  LSAR  system  that  can  be  used  to  completely  satisfy  aH  MIL-STD-1 388-  * 

2A  requirements  with  total  independence  from  any  other  hardware  and  software. 

(a)  SLIC  I 

(b)  SLIC  II 

12.  PLANNING  GUIDANCE:  • 

a.  DURATION:  Update  the  database  continuously  throughout  the  life  of  the  product. 

b.  CONSTRAINTS: 

(1)  Identify  computer  resource  constraints  (examples  include  language,  computer,  data  * 

base,  architecture,  or  interoperability  constraints). 

(2)  Database  capacity  (identify  spare  menwry  and  throughput  requirements.-computer 
memory  growth  requirements,  software  partitioning  and  modular  design  requirements  such  as  software 
module  size  (e.g.,  no  greater  than  100  lines  of  code). 

• 

(3)  Access  capabilities 

(4)  Security  restriclions 

(5)  Time 

(6)  Assumptions 

(7)  Funds 

(8)  Management  Resources  § 

(9)  Training 

c.  RESOURCES: 

(1)  Facilities 

(a)  Classified  work  space  ^ 

(b)  Personnel  office  space  and  supplies 

(c)  Database  location 
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(2)  Ck)nfiputer  hardware  and  software  pro^'arns 

(a)  Analytical  models 

(b)  Program  Management  Software 

(3)  Security 

(a)  Typeof  access  required 

(b)  Provide  access  for  contractors 

(4)  Martpower 

(a)  Security  personnel 

(b)  Computer  systems  personnel 

(c)  Data  management  personnel 

D.  LESSONS  LEARNED:  (Rrsttwolessonstranscribedfrom  ALLCARS,  the  others  are 
referenced). 

(1)  #  1982,  Program  Directors:  Enhanced  quality  and  quantity  of  information  on  the  AFAM 
database.  Improvements  include  additional  lessons  learned  and  best  practices,  updated  references, 
increased  number  of  tools  such  as  software  programs,  document  templates,  samples,  and  courses.  (Col. 
Ferrell,  ASC/CYM,  DSN  785-2213) 

(2)  #1344,  Schedule  Plan  For  A  Source  Selection;  Develop  a  detailed  plan  for  the  execution  of 
source  selection  that  will  aid  the  flow  of  data  and  provide  expedient  changes  to  contingencies.  All  data 
was  computeraed  on  an  IBM  program  called  “Super  Project.*  The  data  were  placed  in  a  network  to 
define  the  internal  relationships  of  activities  and  resources  and  a  Gantt  chart  was  used  to  provide 
schedule  suspense  dates  and  serve  as  a  tracking  tool.  By  computerizing  the  data  base  *v^at-if* 
scenarios  could  be  evaluated  based  on  unknown  contirtgencies  (i.e.,  slip  of  data  reviews,  modifications 
to  the  proposals,  personnel  conflicts  or  absences).  The  database  was  used  as  a  'living  toor  to  he^ 
manage  200  evaluators,  18  evaluation  items,  and  7  proposals.  (PCX)  will  be  added  at  later  date.) 

(3)  #  1264,  AFLC  LMS  Target  Operating  Environment. 

(4)  #1418,  Internal  Financial  Management. 

(5)  #1888,  Program  Managers. 

(6)  #  1982,  Program  Directors. 

(7)  #  9020,  Hardness  Surveillance  Test  Systems  (PHSTS). 

(8)  #  9063,  Air  Force  Electronic  Combat  Office  (AFECO ). 

(9)  #9115,ASIAC. 

(10)  #9116,  Reliability  Analysis  Center  (RAC). 

E.  BEST  PRACTICES: 

Use  MIL-HDBK-59A,  DOD  CALS  Program  Implementation  Guide,  and  MIL-STD-1840A, 
Automated  Interchange  of  Technical  Information  to  control  data  storage  with  frequent  backups  to  avoid 
the  loss  of  data. 

F.  TRAPS: 

(1)  Noncompatible  CALS  systems  have  problems  with  nonstandard  terminology  used  to  file  or 
retrieve  data. 
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1.  ELEMENT:  D74.  TBS  1. 3.3.7  (IFC93-3) 

2.  ELEMENT  TITLE:  Award  and  Issue  Contract(s) 

3.  ELEMENT  OWNER(S):  ASC/PK  (ASC/PKC) 

4.  ELEMENT  STAKEHOLDER(S):  Contracting  Officer  (CO),  Project/Program  Manager  (PM). 
AFMC/PK,  Source  Selection  Authority  (SSA) 

5.  REQUIREMENT: 

a.  Federal  Acquisition  Regulation  (FAR)  Part  4:  Prescribes  policies  and  procedures  for  executing, 
reporting  and  distributing  contract  awards.  See  also  Part  4  of  Defense  Federal  Acquisition  Regulation 
Supplement  (DFARS),  Air  Force  Federal  Acquisition  Regulation  (AFFARS),  Air  Fo^  Materiel 
Command  (AFMC)  and  Aeronautical  System  Center  (ASC)  supplements  for  additional  requirements. 

b.  FAR  Part  5;  Prescribes  policies  and  procedures  for  publicizing  contract  awards.  See  also  Part  5 
of  DFARS,  AFFARS,  AFMC  and  ASC  supplements  for  additional  requirements. 

c.  FAR  Part  1 5:  Prescribes  policies  and  procedures  for  awards  made  by  negotiation  and  the 
required  documentation.  See  al^  Part  15  of  DFARS.  AFFARS,  AFMC  and  ASC  supplements  for 
additional  requirements. 

d.  AFFARS  Part  5301 .901 1 ,  5301 .9012  and  AFMC  Part  5301 .9011;  Prescribes  policies,  procedures 
and  threshold  levels  for  the  Clearance  Process. 

e.  AFMC  FAR  Part  5301 .601-92  Prescribes  when  legal  review  of  contract  documents  is  required. 

6.  PURPOSeOBJECTlVES: 

a.  Purpose:  The  purpose  in  awarding  a  contract  is  to  formalize  Gk>vemment  funded  efforts  into  a 
binding,  legally  enforceable,  contractual  vehicle  between  two  parties,  namely,  the  Government  and  a 
specified  contractor. 

b.  Objectives:  The  objective  is  to  issue  a  contract  which  clearly  reflects  the  agreement  of  the  parties 
and  is  consistent  with  cun'ent  law,  regulation  and  policy. 

7.  DESCRIPTION: 

a.  The  contract  award  process  is  a  combination  of  numerous  document  preparation  activities,  file 
preparation  activities  and  reviews,  which  when  completed,  result  in  the  release  of  a  legally  binding 
contract.  The  main  document  that  needs  to  be  prepared/finalized  is  the  contract  itself.  The  contract  will 
consist  of  Sections  A  through  J  of  the  Request  for  Proposal  (RFP),  amended  as  negotiated  between  the 
parties  or  as  amended  during  the  Source  Selection. 

b.  The  official  contract  file  must,  also,  be  created.  Air  Force  Forni  3019  contains  a  checklist  of 
documentation  that  may  be  required  in  the  contract  file.  The  completed  fonn  is  included  as  part  of  the 
official  file.  The  file  must  contain  all  the  properly  prepared  and  executed  documentation  required  by  law 
and  regulation  in  addition  to  ail  pertinent  correspondence  to  support  the  awarding  of  the  contract.  As  a 
minimum,  the  following  documents  should  be  included;  procurement  directive,  funding  documents, 
correspondence  with  the  contractor,  the  contractor's  pro^al.  eviderKe  of  all  required  approvals,  copies 
of  briefings  made,  technical  evaluations,  pricing  memorandum,  legal  and  contract  clearance 
coordination,  and  evidence  of  contractor  acceptance  of  the  contract  and  agreement  with  all  of  the  terms 
and  conditions  therein. 
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c.  The  team  required  to  generate  and/or  pull  these  documents  together  consist,  mainly  of  the  CO, 
PM,  Contract  Negotiator,  and  the  Price  Analyst  (it  different  from  the  negotiator).  As  soon  as  negotiations 
are  completed,  the  contract  negotiator  begins  to  ircorporate  the  agreed  to  changes  required  to  the 
contractual  document  and  the  file  documentation.  This  would  include  documenting  in  the  contract  any 
special  clauses  or  requirements  that  were  negotiated  arxf  the  completion  of  the  pricing  memorandum  to 
describe  the  agreement  of  the  parties.  In  a  Source  Selection,  it  is  customary  to  have  a  contract  ready  to 
be  issued  incorporating  agreed  to  changes  for  each  offeror  prior  to  the  SSA  decision. 

d.  When  these  documents  are  complete,  the  review/approval  process  begins.  The  review  process 
begins  with  Contracting  Officer  and  legal  review  of  the  corrtract  and  contract  file.  These  initial  reviews 
must  take  place  prior  to  the  contractor  execution  of  the  contractual  document.  Legal  review  after 
contractor  execution  of  the  document  is  only  retired  if  the  contractor  has  made  some  type  of  change  to 
the  document  or  taken  exception  to  somethir^  in  the  document.  After  CO  and  legal  review,  the  contract 
must  be  reviewed/approved  in  accordance  with  the  Contract  Clearance  procedures  cited  in  AFFARS  Part 
5.301 .  Contract  Clearance  is  not  required  for  competitive  acquisitions  unless  specifically  requested  by 
the  CO  or  directed  by  the  Corttract  Clearance  approving  authority.  Some  reasons  to  request  a 
competitive  clearance  would  be  if  competition  was  not  realized  or  significant  issues  remain  urisolved. 
Noncompetitive  acquisitions  are  required  to  go  through  the  Contract  Clearance  process. 

e.  The  review/approving  authorities  are  determined  by  the  dollar  threshold  and  type  of  program 
(Major/Selected/Other  Progranrts/Other  Contracting).  Tat^  I  set  forth  in  the  AFFARS  Part  5301  is 
applicable  to  Major,  Selected  and  Other  Programs.  Table  II  cited  in  AFMC  5301 .9000  set  forth  approval 
thresholds  for  Base  Support  /Sustainment  (Other  Contracting)  actions.  The  format  for  a  Request  for 
Contract  Clearance  (RCC)  is  shown  at  AFFARS  part  5301  Figure  1-B.  To  accompany  the  request,  a 
package  consisting  of  the  negotiated  contract,  the  price  negr^iation  memo,  and  an  abbreviated  version 
of  the  contract  file  must  be  prepared  by  the  contract  negotiator/contracting  officer.  The  documents  to  be 
included  in  the  RCC  version  of  the  contract  file  are  the  contractor's  certificate  of  current  cost  and  pricing 
data,  a  copy  of  the  audit  report,  the  funding  documents,  the  legal  review  and  the  DD  Form  350, 

Individual  Procurement  Action  Report. 

8.  ENTRANCeEXIT  CRITERIA: 

a.  Entrance:  The  contract  award  process  begins  after  the  selection  of  the  winning  contractor  by  the 
Source  Selection  Authority  or  at  the  conclusion  of  negotiations  in  a  noncompetitive  acquisition  (Blo^ 
D70). 

b.  Exit;  The  contract  award  process  ends  at  distrfoution  of  the  approved  contractual  document  to 
the  contractor  (Block  029)  and  other  required  offices. 

9.  KEY  INPUTS  AND  OUTPUTS; 

a.  Inputs:  The  key  inputs  to  the  contract  award  process  depend  on  whether  the  acquisition  was  a 
competitive  Source  Selection  or  noncompetitive  negotiation. 

1 .  In  a  Source  Selection,  the  required  input  prior  to  a  contract  award  is  the  Source  Selection 
Decision  Document.  This  document  signed  by  the  Source  Selection  Authority  sets  forth  the  rationale  in 
support  of  the  decision,  and  is  sent  to  the  CO  as  direction  to  execute  the  selected  contract  (Block  D70). 

2.  In  a  noncompetitive  negotiated  acquisition  the  key  inputs  are  the  various  reviews  that  take 
place  and  the  resulting  comments  and  corrections  to  the  contract  document  and  supporting  file 
documents.  Depending  on  the  dollar  threshold  (see  AFFARS  1 .901 1 ),  these  reviews  may  be  conducted 
by  some  or  all  of  the  following;  the  CO,  Judge  Advocate  General  Office  (JAG),  Business  Clearance 
organizations,  the  Program  Executive  Officer  (PEO),  the  Defense  /Vcquisition  ^ard  (DAB)  and  the 
Contract  Clearance  authority.  These  various  reviews  examine  the  contract  document  itself  for 
compliance  with  all  applicable  laws,  regulations  and  policies.  The  contract  file  and  its  supporting 
documents  are  reviewed  to  determine  if  they  adequately  support  and  justify  the  acquisition  as  negotiated. 
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b.  Outputs:  The  resuHing  output  of  the  contract  award  process,  for  both  a  Source  Selection  and  a 
negotiated  acquisition,  is  a  legally  binding  contract. 

10.  KEY  REFERENCES:  In  addition  to  the  above  listed  regulations,  AF  Regulations  70-30  and  70-15 
prescribe  contract  award  policies  and  procedures  arxf  required  documentation  for  the  Source  Selection 
process.  The  Armed  Services  Pricing  Manual  (ASPM)  describes  the  contents  of  the  pricing 
memorandum. 

11.  IMPLEMENTATION  TOOLS: 

a.  A  tool  that  is  quite  helpful  when  it  comes  to  creating  the  contract  file  and  preparing  for  the 
contract  clearance  process  is  the  review  checklist  (updated  semiannually  by  ASC/PK  Policy  Letter).  This 
checklist  is  intended  as  a  guide  for  contract  negotiators.  Contracting  Officers  and  reviewers.  The  guide 
is  arranged  to  be  consistent  with  the  AF  Form  3019  (Contract  File  Content  Checklist).  As  a  minimum, 
action,  events,  and/or  file  documentation  suggested  by  the  checklist  should  be  considered  prior  to 
contract  award.  The  checklist  addresses  each  file  item,  provides  the  applicable  reference  source  in  the 
regulations,  and  prompts  questions  to  ensure  that  the  file  item  has  been  completed  and  conr^ileted 
property. 

b.  One  tool  to  aid  in  preparing  the  price  negotiation  memorandum  is  a  model  PNM  format  generated 
in  ASC/PKF  while  an  AFMC  Form  368  provides  a  PNM  checklist. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  The  estimated  time  frames  to  award  a  contract  vary  greatly  with  the  complexity, 
dollar  amount  of  the  acquisition,  and  type  of  acquisition  (competitive  vs.  noncompetitive).  A  small  ^llar, 
noncomplex  award  could  be  accomplished  in  as  little  as  a  week  or  two.  In  contrast,  one  large  dollar, 
rather  complex,  high  visibility  award  took  a  year  from  the  end  of  negotiations  to  obtain  the  final  approval 
to  award  the  contract.  A  Contract  Clearance  review  is  estimated  to  take  2-4  days  if  the  file  and 
documents  have  been  previously  reviewed  at  the  Business  Clearance.  If  no  previous  review  was 
accomplished,  the  Contract  Clearance  could  take  several  weeks.  In  addition,  if  the  reviews  indicate  that 
changes  are  required,  the  contract  negotiator  would  need  time  to  make  the  con-ections  arxf  to  obtain  the 
Contractors  re-execution  of  the  contract  document. 

b.  CONSTRAINTS:  A  variety  of  sources  could  constrain  or  delay  the  awarding  of  the  contract.  At 
each  review  level  (CO,  JAG.  Clearance  Authority,  DAB),  comments  and  recommendations  will  be 
provided  to  the  contract  negotiator.  Each  comment  must  be  addressed  and  resolved  to  the  reviewer's 
satisfaction.  A  CO  will  not  normally  sign  a  contract  with  unresolved  review  comments.  Before  the 
contractor  signs  the  contract,  he  will  conduct  his  own  review  of  the  contractual  documents.  If  the 
contractor  takes  exception  to  something  in  the  contract,  the  problem  must  be  resolved  before  the  CO 
signs  the  document. 

c.  RESOURCES:  The  contract  award  process  is  primarily  a  function  performed  by  the  project  team/ 
program  office  contracts  personnel.  While  some  inputs  are  required  from  other  functional  areas,  such  as 
program  management,  finance,  arrd  engineering  for  contract  file  documents,  the  responsibility  to  write 
the  contract  and  support  the  acquisition  with  an  adequate  contract  file  falls  on  the  contracting  function 
and,  specifically,  the  Procuring  Contracting  Officer.  If  the  acquisition  was  one  which  required  ASC/PKF 
pricing  support  (see  ASC  FAR  Supplement  15.805-1),  the  assigned  price  analyst  is  a  very  critical 
resource.  In  addition  to  prenegotiation  pricing  efforts  such  as  proposal  evaluation  and  Business 
Clearance  preparation,  the  price  analyst  will  support  all  negotiations  and  be  responsible  for  Contract 
Clearance  dor^mentation  and  justification. 
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d.  LESSONS  LEARNED: 

a.  As  a  contract  negotiator,  it  is  very  important  to  create  a  contract  file  that  fully  supports  the 
acquisition.  All  correspoixfence  with  the  successful  contractor  (filed  chrorxjlogically  from  oldest  to  most 
recent)  must  be  included  in  the  file,  including  all  documents  that  the  correspondence  reference.  If  these 
references  are  not  pertinent  to  the  acquisition  and/or  the  bulk  of  these  references  is  too  great,  annotate 
where  these  documents  can  be  located. 

b.  Review  the  contract  file  checklist  to  ensure  that  all  required  file  items  have  been  included 
prior  to  any  of  the  reviews  taking  place.  Some  documents  that  will  be  scrutinized  very  closely  are 
discussed  below; 

1 .  The  pricing  memorandum  is  the  primary  document  which  must  fully  explain  the 
acquisition,  the  agreement  of  the  parties,  and  the  rationale  used  to  determine  that  this  acquisition  is  fair 
and  reasonable  to  both  the  Government  and  the  contractor.  In  a  Source  Selection,  the  pricing 
memorandum  is  called  the  "Price  Competition  Memorandum  (PCM),*  and  in  a  neg^iated  acquisition,  the 
pricing  memorandum  is  called  the  "Price  Negotiation  Memorandum  (PNM)." 

2.  Probably  the  most  important  document  that  the  CO  will  look  at  to  ensure  its  propriety  and 
accuracy  is  the  funding  documents.  The  CO  is  obligating  the  Government  to  pay  by  signing  the  contract 
and  therefore  must  be  very  sure  that  adequate  funds  are  available  and  that  the  funds  are  proper  for  this 
type  of  acquisition. 

3.  Another  very  important  document  to  be  inchjded  in  the  contract  file  is  the  Certificate  of 
Current  Cost  arid  Pricing  Data.  This  document  is  the  contractor's  certification  that  all  pricing  data 
supplied  to  the  Government  is  current  and  accurate  as  of  the  date  negotiations  were  completed. 

c.  In  the  case  where  there  is  a  claim  against  the  Government  or  litigation  involving  the 
acquisition,  it  is  critical  that  the  file  documentation  be  complete  and  accurate.  The  contract  negotiator  or 
the  CO  may  not  be  available,  due  to  reassignment  or  resignation,  to  explain  or  answer  questions 
regarding  the  acquisition.  The  contract  file  is  the  official  record  of  the  specifics  of  the  acquisition  and 
must  stand  on  its  own  merits. 

e.  BEST  PRACTICES:  In  a  noncompetitive  award,  the  Business/Contract  Clearance  process 
requires  that  a  draft  of  the  contract,  preliminary  PNM,  and  appropriate  contract  file  items  be  written  and 
prepared  prior  to  entering  negotiations.  This  reduces  the  time  required  after  completion  of  negotiations 
to  draft  the  contract  and  the  required  backup  documentation.  Of  course,  it  is  very  unlikely  these 
documents  will  remain  unchanged  by  the  negotiation,  but  it  requires  much  less  time  to  correct  and  revise 
these  documents  than  to  generate  them  from  scratch.  It  is  best  to  have  the  file  and  contract  as  complete 
as  possible  at  the  time  of  the  Business  Clearance. 

f.  TRAPS:  In  the  instance  where  an  accelerated  contract  award  is  required,  the  contract  negotiator 
should  alert  the  review  activities  of  the  urgency  well  in  advance  of  presenting  the  documents  for  review. 
Instead  of  waiting  for  the  entire  review  package  to  be  completed,  the  reviewer  may  agree  to  review 
documents  as  the  negotiator  finalizes  them.  Reviewers  do  not  like  to  be  rushed  and  surprised  at  the 
same  time.  Though  the  contracting  community  bears  most  of  the  responsibility  for  the  award  of  the 
contract,  the  rest  of  the  program  team  will  often  be  asked  to  write  file  memos  and  review  and  critique 
clauses  as  a  result  of  the  contract  review. 
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1.  ELEMHENT;  D75.  TBS  1 .3.4.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Assign  Lead  and  Support  Centers 

3.  ELEMENT  OWNER(S):  HQ  AFMC/XP 
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4.  ELEMENT  STAKEHOLDER(S):o  All  Product  and  Logistic  Centers,  Functional  Home  Ottices,  Center 
XRs  and  ASC/YX,  System  Procyct  Offices,  AFMC  Laboratories,  Test  Centers,  and  Single  Managers 

5.  REQUIREMENT:  Draft  Policy  Directive  entitled;  AFMCCPD  XX-XX.  AFMC  Mission  Assignment 
Process  and  the  accompanying  draft  Mission  Planning  Instruction  for  the  Mission  Assignment  Process. 
(Both  of  these  documents  are  in  their  early  stages  of  evohJtion,  the  draft  is  dated  1 0  Feb  93  and  does  not 
yet  have  a  Policy  Directive  numerical  identifier.)  When  finalized,  this  Policy  Directive  and  its  attached 
Mission  Planning  Instruction  will  supersede  the  following: 

-  AFMCR  523-1  .Mission  Assignment  Policy 

-  AFMCR  523-3,  AFMC  Mission  Assignments 

-  HQ  OI  523-1 ,  Notification  of  AFMC  Mission 

Assignments  and  Reassignments 

-  HQ  OI  523-2,  Headquarters  AFMC  Mission  Assignment 

Source  Selection  Process 


6.  PURPOSE  AND  OBJECTIVES: 

a.  PURPOSE:  The  AFMC  Mission  Assignment  Process  was  established  to  ensure  all  the 
taskings  which  come  into  the  command  are  accomplished  by  the  most  capable  and  qualified 
organization. 

b.  OBJECTIVES:  The  overall  objective  of  establishing  and  institutionalizing  the  AFMC  Mission 
Assignment  process  is  to  ensure  the  command  does  its  best  to  satisfy  the  customers  by  providing: 

-  quality  service, 

-  quality  products, 

-  timely  response  to  customer  needs, 

-  best  value  to  the  customer  and  the  command  by  using  the  most  qualified  and  appropriate  resources, 

-  consistency. 

These  objectives  are  driving  forces  the  command  wants  to  capture  through  the 
application  of  the  Mission  Assignment  Factors. 
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7.  DESCRIPTION:  The  process  described  here  is  identical  to  the  process  conducted  following  the  * 

release  of  the  Phase  0  Program  Management  Directive  (PMD)  (D21 ).  The  main  differences  are  that  the 

category  I  mission  taskings  are  very  rare  at  this  phase  of  a  project.  I^t  it  is  very  common  around  the 

Milestone  0  vicinity.  The  other  major  difference  is  that  the  execution  of  the  process  described  in  D21  is 

more  the  exception  than  the  rule  -  here  the  process  will  nearly  always  be  exercised. 

The  AFMC  Mission  Assignment  Process  is  the  first  major  action  taken  by  HQ  AFMC  following  the 

release  of  the  Phase  I  PMD  by  Air  Staff  (B25).  The  PMD  gets  the  ball  rolling  by  including  the  phrase  • 

"AFMC  shall...".  With  such  a  tasking  in  hand,  AFMC/XP  then  makes  mission  assignments  to  the 

appropriate  center  based  on  a  set  of  objectively  measurable  criteria  including  areas  concerning; 

-  customer  rer^irements, 

-  technical  characteristics  of  the  proposed  assignment, 

-  the  present  and  future  posture  of  the  command, 

-  and  the  overall  needs  of  the  Air  Force  and  DoD.  0 

It  is  important  to  remember  that  this  is  an  AFMC  process,  it  does  not  apply  to  assignments  to  single 

program  managers  (these  are  handled  through  the  PEO/DAC  chain  of  command),  or  to  mission 
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assignments  within  a  particular  laboratory  or  center  which  are  handled  by  the  respective  commander.  At 
ASC,  the  ASC/CC  makes  the  work  assignments  within  the  center  through  the  Review  New  Work  Process 
where  lead  and  support  organizations  are  finalized  (079).  ^ 

The  Mission  Assingment  Process  is  applicable  to: 

o  initial  assignments,  realignments,  and  rescissions  of  AFMC  management  responsibilities  for. 

-  weapon  systems, 

-  support  systems, 

-  technology  groupings, 

-  Federal  Supply  Classification  (FSC)  items,  • 

-  special  programs, 

-  special  projects: 

-  initial  source  of  repair  (SOR)  for  major  systems  and  engines. 

The  assignments  made  at  this  level  deal  primarily  with  the  manner  in  which  the  AFMC  infrastructure 

provides  resources  and  capabilities  to  the  single  managers  and  other  external  customers  and  aibws  their  ^ 

management  processes  to  operate. 

In  order  to  ensure  efficiency  and  responsiveness  in  the  mission  assignment  process,  AFMC  has 
divided  the  various  types  of  taskings  or  work  which  come  into  the  command  into  three  categories. 

-  Category  I  assignments  are  those  taskings  which  are  non-Program  Management  Directive 

(PMD)  generated.  They  originate  with  the  customer,  who  takes  the  task  directly  to  the  center  that  the  * 

customer  feels  is  the  best  qualified  to  do  the  work.  Basically,  Category  I  taskings  by-pass  the  entire 
AFMC  mission  assignment  process.  (This  category  of  taskings  are  generally  dealt  with  in  the  pre- 
Milestone  0  time  frame.) 

A  hypothetical  may  help.  Assume  Air  Combat  Command  (ACC)  has  walked  through  their 

mission  area  assessment  (C1 )  and  preliminary  mission  need  analysis  (MNA)(C3)  using  the  strategy-to-  * 

task  technique.  They  discover  there  may  be  a  shortfall  in  their  ability  to  destroy  relocatable  targets  such 

as  SCUDs.  Armed  with  this  information,  ACC  comes  to  ASC/XR  requesting  them  to  do  further  analysis 

on  this  potential  shortfall  and  to  discover,  if  possible,  what  areas  pertaining  to  SCUD  Killing  are  deficient, 

(i.e.  Mission  Need  Analysis).  ASC/XR  runs  an  entire  battery  of  analytical  excursions  using  a  variety  of 

models.  They  assess  the  tactics  employed,  the  airframes  tasked  with  this  mission,  types  and  numbers  of 

weapons  used,  availabilKy  of  intelligence,  etc.  • 

At  the  same  time  all  this  is  going  on  between  ACC  and  ASC,  Space  Command  discovers  the  same 

shortfall  in  their  own  MAA.  In  Space  Command's  shortfall,  they  think  their  deficiency  lies  in  their  inability 

to  direct  a  laser  energy  weapon  against  a  detected  SCUD  launch  point.  Space  Command  engages  the 

services  of  SMC/XR  to  accomplish  the  MNA  activities  and  provide  the  detailed  analysis  which  show  what 

specific  areas  in  the  Space  Command's  SCUD  Killing  mission  are  deficient.  SMC/XR's  initial  analysis 

hints  that  the  most  efficient  way  to  kill  SCUDs  might  not  necessarily  be  from  a  satellite  platform.  In  order  ^ 

to  explore  this  possibility  SMC  employs  the  services  of  ESC/XR.  ESC  will  do  preliminary  analysis  on  the 

possibility  of  improving  the  Communication  links  with  more  earthbound  strikers  such  as  tanks,  surface-to- 

surface  missiles,  orbiting  aircraft  etc. 

In  this  hypothetical  example,  three  significant  taskings  were  created,  assigned,  and  accomplished  totally 
outside  the  AFMC  Mission  Assignment  Process.  This  is  the  rwrm  in  Pre-Milestone  0  activities. 

AFMC/XP  has  no  wish  to  interfere  with  this  practice,  without  a  PMD  or  some  other  kind  of  higher  ^ 

headquarters  tasking  document;  the  AFMC  Mission  Assignment  Process  is  not  a  player.  Other  types  of 
taskings  which  would  fall  into  Category  I  would  be  things  like:  Military  Interdepartmental  Purchase 
Requests  (MIPRs),  another  service's  request  for  work  which  is  provided  directly  to  specific  Test  Center 
with  previously  assigned  responsibility  for  that  type  of  test  activity,  etc. 

-  Category  II  assignments  are  generally  those  taskings  resulting  from  PMD  revisions  in  which 

similar,  related,  or  follow-on  work  is  directed  to  a  single  manager.  Category  II  tasks,  like  the  Category  I  * 

tasks,  already  have  the  management  infrastructure  in  place.  The  difference  here  is  that  Category  II 
tasks  operate  under  a  dual  management  infrastructure.  The  single  manager's  infrastructure  operates 
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within  the  acquisition  chain  of  command  and  in  conjunction  with  the  AFMC  infrastructure.  AFMC  is  to 
provide  the  single  manager  (along  with  other  internal  and  external  customers)  with  the  resources  and 
capabilities  which  might  currently  be  lacking  in  the  single  manager's  operation.  If  the  single  manager 
already  has  all  the  assets  he  needs  to  complete  this  new  tasking,  then  AFMC  is  out  of  the  picture. 

Again  a  hypothetical  example  might  make  this  a  little  easier  to  understand.  Assume  that  Wright 
Laboratory  discovers  an  electronic  device  which  when  installed  in  the  avionics  suite  of  a  B-1 B  renders 
the  entire  air  vehicle  as  stealthy  as  a  B-2.  The  concept  is  reviewed  by  ACC  and  they  like  it  and  they 
want  it  installed  on  their  entire  B-1  B  fleet.  The  B-1  B  Program  Element  Monitor  manages  to  get  the  B-1  B 
PMO  amended  to  included  the  integration  of  the  new  miracle  "cloaking  device."  Along  with  the  amended 
PMD  comes  $1 OOM  to  install  and  integrate  the  devices  into  the  B-1  B  avionics  suite.  The  devices 
themselves  will  be  produced  by  the  lab  and  provided  as  GFE.  The  Single  Manager  for  the  B-1  B  would 
receive  this  update  to  the  PMD.  In  order  to  assess  his  ability  to  accomplish  this  task,  he  might  form  an 
Integrated  Product  Team  (IPT)  to  research  the  task  and  the  resources  required  to  complete  it.  The  IPT 
completes  their  effort  and  determines  that  they  will  need  some  assistance  from  ASC/EN  for  more 
avionics  engineers,  as  well  as  a  whole  host  of  folks  from  the  other  functional  home  offices  as  well.  This 
would  be  a  tasking  internal  to  ASC's  structure  (Category  I  type)  and  would  still  not  require  AFMC's 
involvement.  The  IPT,  however,  had  no  idea  as  to  who  would  be  the  best  Center  for  performing  the 
depot  level  maintenance  on  the  "cloaking  devices"-  now  the  AFMC  Mission  Assignment  kicks-in.  (If  the 
IPT  had  determined  that  Oklahoma  City  ALC  would  do  the  depot  work  on  the  boxes  and  the  single 
manager  would  have  tasked  them  to  do  so,  AFMC  might  still  have  become  involved  if  Oklahoma  City 
would  have  told  the  single  manager  they  were  unable  to  accomplish  the  new  tasking  and  referred  the 
work  back.  In  this  case,  the  single  manager  should  contact  the  appropriate  HQ  AFMC  functional 
organization.)  At  this  point  AFMC  has  several  options  to  pursue  including  making  a  new  mission 
assignment  through  the  Category  III  assignment  process. 

-  Category  III  assignments  are  the  New  Mission  assignments  and  generally  arrive  on  AFMC’s 
doorstep  via  a  new  PMD.  Other  less  common  sources  of  new  mission  taskings  include  the  Operational 
Requirements  Document  (ORD),  other  formal  requests,  or  as  a  result  of  Internal  management  processes. 
New  assignments  include  activities  for  a  new  program,  technology,  federal  stock  class  and/or  any  other 
new  form  of  workload  tasked  to  AFMC  for  development,  testing,  program  management,  and/or  support. 
Major  mission  reassignments  and  those  taskings  spilling  from  the  Category  II  example  above  are  also 
included  in  this  category.  Category  III  assignments  are  those  which  rvarmally  come  to  mind  when 
considering  the  Mission  Assignment  process. 

-  EXAMPLES;  A  couple  of  last  examples  should  bring  home  the  differences  in  the  three 
categories.  First,  the  easy  one,  ACC  in  conjunction  with  ASC/XR  has  completed  the  MNA  for  shortfall  in 
the  multirole  fighter  force.  The  initial  analysis  showed  a  serious  deficiency  starting  in  the  year  2010. 

ACC  drafts  and  staffs  a  Mission  Needs  Statement  (MNS)  to  explore  various  concepts  which  could  solve 
this  deficiency.  The  MNS  works  it  way  to  the  Joint  Requirements  Oversight  Council  (JROC)  where  the 
need  is  validated.  The  JROC  attaches  their  assessment  of  the  need  and  forwards  the  package  to  the 
Defense  Acquisition  Board  (DAB)  for  the  Milestone  0  review.  A  favorable  review  results  in  an  Acquisition 
Decision  Memorandum  (ADM)  which  is  converted  into  a  PMD  by  the  Air  Staff.  This  PMD  tasks  AFMC  to 
conduct  Concept  Exploration  and  Definition  (CE&D)  activities  necessary  to  develop  a  solution  set  to 
resolve  the  deficiency  in  the  current  multirole  force.  In  this  example  the  center  best  capable  of  handling 
this  tasking  would  be  ASC  since  they  are  the  aircraft  developers.  After  receiving  the  PMD.  AFMC/XP 
would  review  the  task  and,  in  this  case,  send  direct  to  the  ASC/CC  where  it  would  enter  into  the  /^C 
New  Work  Review  Process  (D79)  tor  internal  assignment. 

-  Category  III  (continued):  The  second  example  is  not  nearly  as  cut-and-dried  as  the  first. 

Let's  assume  the  multirole  forces  CE&D  activities  from  the  previous  example  result  in  a  new  aircraft 
program,  the  F-XX.  The  PMD  from  that  Milestone  II  decision  directs  AFMC  to  provide  Logistical  and 
Depot  Level  Support  for  the  future  F-XX.  IN  this  case,  the  Center  to  receive  this  tasking  is  not  nearly  as 
clear-cut.  Should  it  be  Sacramento  because  they  have  the  most  experience  working  with  composite  type 
airframes  or  should  it  be  Oklahoma  City?  Why  not  Hill,  since  they  have  the  most  experience  with 
previous  multirole  aircraft?  What  if  Robbins  has  the  most  facilities  and  manpower  available  to  handle 
such  a  large  task? 
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An  even  better  example  would  be  a  derivative  of  the  Natior^al  Aerospace  Plane 
(NASP)?  It  is  part  airplane  (ASC's  home  turf)  and  part  space  system  (SMC's  kingdom).  To  resolve  this 
issue,  AFMC/XP  rurrs  through  the  following  flow. 

The  details  for  each  of  these  21  boxes  as  well  as  the  activity  flows  for  the  Labs,  FSC,  and  Test  mission 
assignment  sub-process  flows  can  be  found  in  the  10  Feb  SO  draft  of  the  Mission  Planning  Instruction  tor 
the  AFMC  Mission  Assignment  Process.  A  few  of  the  more  critical  steps  are  provided  below: 

Once  the  PMD  (or  other  tasking  element)  is  received,  an  action  officer  is  assigned  to  determine  project 
validity  as  a  Category  III  tasking.  In  this  example  it  is,  so  the  action  officer  runs  the  diamond  gauntlet 
and  determines  the  ta^  should  go  to  one  of  the  logistic  centers,  so  he  enters  the  task  into  the  logistic 
center  mission  assignritent  subprocess.  The  Center  Commanders  and  single  managers  review  the  task 
and  assign  a  series  of  multiplying  weights  to  be  applied  against  each  of  the  standard  measurement 
factors.  For  example,  if  the  task  were  to  select  the  logistics  support  for  a  B-3  bomber,  then  facilities 
might  be  a  highly  weighted  item  or  in  this  example  if  the  F-XX  were  a  'thermoplastic''  jet  then  technical 
experience  with  composite  materials  would  be  a  big  player.  The  individual  centers  are  objectively 
measured  against  each  of  the  factors.  AFMC/XPX  will  then  assemble  the  results  and  put  together  a 
Recommended  Assignment  Package  for  review  and  approval  by  the  Program  Management  Mission 
Element  Board  (PMMEB).  The  winner  is  then  notified  of  the  results.  If  all  goes  according  to  the  book, 
the  most  capable  logistics  center  should  now  be  in  charge  of  all  F-XX  support  operations. 

8.  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance  into  this  process  occurs  with  the  receipt  of  the  Milestone  I  PMD  from  HC  aF/XOR 

(B25). 


b.  Exit  criteria  have  been  met  when  AFMC/XP  assigns  the  new  mission  task  to  one  of  the 
command  centers  of  excellence  for  execution.  In  the  case  of  ASC,  the  task  will  enter  into  the  ASC  New 
Work  Review  process  for  internal  allocation  (D79). 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Key  input  is  the  tasking  document  which  is  normally  the  PMD  (B25).  Taskings  may  also 
come  from  ORDs,  verbal  requests,  or  some  AFMC  internal  realignment  activity  and  the  resulting 
documentation. 

b.  The  key  output  is  the  New  Mission  Assignment  Notification  Letter  (Letter  of  Assignment)  to 
the  cerrter  awarded  the  new  mission  and  possibly  a  notification  package  to  Congress  explaining  the 
rational  for  the  decision.  The  Letter  of  Assignment  is  then  used  by  the  selected  product  or  logistic  center 
to  select  the  appropriate  product  and  support  organization  within  the  center  (D79).  At  ASC  the  New 
Work  Review  Process  is  the  vehicle  for  making  this  happen. 

10.  KEY  REFERENCES: 

a.  Draft  Policy  Directive  entitled.  AFMCCPD  XX-XX,  AFMC  Mission  Assignment  Prcx;ess  and 
the  accompanying  draft. 

b.  Mission  Planning  Instruction  tor  the  Mission  Assignment  Process.  (Both  of  these  documents 
are  in  their  early  stages  of  evolution,  the  draft  is  dated  10  Feb  93  and  does  not  yet  have  a  Policy 
Directive  numerical  identifier.) 

1 1 .  IMPLEMENTATION  TOOLS:  Each  of  the  center  subprocess  activity  flows  are  included  in  the  above 
reference  documents  along  with  a  very  brief  description  of  each  of  the  activity  blocks.  At  the  present 
time  this  is  the  extent  of  the  mission  assignment  tool  set. 
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1Z  PLANMNG  GUIDANCE: 

a.  DURATION:  Regardless  of  acquisition  category,  the  mission  assignment  process  must  be 
completed  in  no  more  than  28  days.  This  is  the  time  required  by  Air  Staff  to  turn  the  PMD.  Strat^ic 
planers  would  be  wise  to  allow  for  the  full  28  days  for  tasks  where  center  competition  is  lAely  (as  in  the 
second  Category  III  example).  For  tasks  that  are  relatively  clear  cut  plan  for  half  that  time. 

b.  CONSTRAINTS:  The  constraints  to  being  awarded  a  new  work  task  are  basically  the 
organizations  ability  to  fully  satisfy  the  factors  being  considered  for  the  task.  The  factors  are  generally 
the  same  for  all  tasks,  but  the  weighted  multipliers  change  given  the  unique  characteristics  of  the  task 
beingconsidered.  Again,  seethe10Feb93  draft  of  the  Mission  Ptannkio  Instruction  for  the  AFMC 
Mission  Assignment  Process  for  a  complete  listing  of  these  factors. 

c.  RESOURCES:  Basically  the  only  resources  required  to  accomplish  the  Mission  Assignment 
Process  are  the  total  availability  of  one  AFMC/XPX  action  officer  for  30  days  and  the  availability  of  all 
the  center  CCs  (or  designated  representatives)  for  a  day  Program  Management  Mission  Element  Board 
(PMMEB).  In  order  for  a  center  to  win  a  new  work  assignment,  resource  availability  will  be  a  key  factor. 


d.  LESSONS  LEARNED: 


None  identified. 


e.  BEST  PRACTICES:  Given  the  relatively  quick  tum-around  time  (by  acquisition  time  scales), 
it  is  a  good  idea  for  individual  organizations  to  have  a  ready  assessment  of  their  excess  capabilities.  If  a 
center  wants  to  compete  for  a  piece  of  new  work,  they  will  likely  pulse  each  of  their  individual 
organizations  to  determine  their  net  capability  to  handle  the  new  task. 

f.  TRAPS:  In  regards  to  the  above  best  practice,  do  not  over  estimate.  Should  a  center  be 
awarded  a  new  work  assignment  based  on  an  over  inflated  estimate  of  its  capability,  the  result  could  be 
much  worse  than  not  getting  the  assignment  at  all.  It  has  happened  before  and  will  IScely  happen  again. 
A  failure  to  perform  a  task  due  to  over  estimate  in  capc^ility  could  jeopardize  the  center's  credibility  in 
future  new  work  assignments  (past  performance  is  one  of  the  measurement  factors). 
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1.  ELEMENT:  D76,  TBS  1 .3.6.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Establish  System  Program  Office  (SPO)  (Lead  Center) 

3.  ELEMENT  OWNER(S):  ASC/CC  (ASC  Only) 

4.  ELEMENT  STAKEHOLDER(S):  ASC/YX.  PEOs.  Program  Managers 

5.  REQUIREMENT:  While  no  current  regulation  governs  the  establishment  of  a  SPO  (See  Paragraph 
10),  the  intent  the  rescinded  documents  should  be  foliowed. 

6.  PURPOSE/OBJECTIVES: 

a.  Purpose;  An  Air  Force  System  Program  Office  is  established  in  order  to  assemble  in  a  central 
physical  location  all  of  the  rer^ired  management  and  functional  representatives  needed  to  execute  a 
program  on  a  day  to  day  basis. 

b.  Objectives:  The  SPO  philosophy  is  to  assemble  the  appropriate  number  of  people  with  the 
required  management  and  functional  expertise  and  dedicate  them  solely  to  the  successful  execution  of 
the  program. 

7.  DESCRIPTION:  After  a  successful  Milestone  l/IV  decision,  a  SPO  cadre  expands  into  an  existing  or 
new  SPO  to  accomplish  all  the  tasks  and  activities  required  during  the  remaining  phases  of  the 
acquisition.  While  a  new  SPO  may  be  formed  to  support  a  single  program,  this  is  usually  only  the  case 
in  major,  high  priority  acquisitions.  In  many  cases,  SPOs  are  formed  to  bring  together  management  and 
functional  expertise  which  would  be  used  to  support  a  number  of  smaller  similar  projects  or  programs 
(basket  SPO). 

Under  the  concept  of  Integrated  Weapon  System  Management  (IWSM),  a  single  manager  is  established 
for  a  particular  system,  product,  or  materials  acquisition.  This  single  manager  is  responsible  for  all 
asp^s  of  the  project/program.  To  assist  the  single  manager,  Centers  of  Excellence  (COE)  will  be 
designated  (or  the  development/production  of  projects  arKf  the  sustainment  of  projects.  The  intent  of  the 
COE  is  to  have  pools  of  experienced,  product-focused  people  to  work  the  programs. 


•  i 


8.  ENTRANCeEXIT  CRITERIA: 

a.  Entrance;  The  formal  establishment  of  a  new  System  Program  Office  can  start  from  either  a 
Program  Management  Directive  (PMD)  tasking,  an  Acquisition  Decision  Memorandum  (ADM)  issued 
after  a  Defense  Acquisition  Board  (DAB),  a  decision  by  the  Center  Commander,  or  a  directive  from  the 
Air  Force  Materiel  Command  Commander  (AFMC/CC).  The  integrated  Flow  Chart  (IFC)  blocks  that 
illustrate  the  direction  are  Block  B25,  Block  D75,  and  D79.  After  receipt  of  direction,  the  first  task  of  the 
Center  Commander  is  to  assign  a  Program  Director  for  the  effort.  This  assignment  may  be  influenced  by 
the  AFMC  Commander.  The  Program  Director  staffs  and  organizes  the  System  Program  Office. 

b.  Exit;  Once  the  initial  organization  and  staffing  of  the  SPO  has  been  accomplished,  this  block  is 
concluded.  The  SPO  will  then  begin  day  to  day  operations  which  will  include  participation  with  Industry 
(Block  D29)  and  continued  project/program  development  (Block  D30).  Industry  participation  is 
accomplished  ^  the  establishment  of  a  contractual  relationship  (Block  D74).  It  should  be  noted  that  the 
SPO  organization  and  resources  do  not  remain  static;  they  must  constantly  change  as  the  program 
requirements  evolve. 


D-591 


'4 


NbvM 


9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  The  key  inputs  in  establishing  a  SPO  would  be  the  direction,  funding,  and  the  numbers, 
types,  skills,  and  experience  of  people  required  to  perform  the  program  tasking.  The  functional  home 
offices  would  assess  the  direction  and  the  project  taskings  against  the  manpower  authorizations  of  the 
assigned  acquisition  organization,  and,  if  needed,  assign  additiortal  functional  support  to  the  new  SPO. 

b.  Outputs;  Program  execution. 

10.  KEY  REFERENCES:  Air  Force  Systems  Command  (AFSC)  Regulation  550-12  Activation  of 
System  P^ram  Offices  (SPO)  and  AFSC  R^ulation  550-20,  Appropriate  Front-Loading  of  Manpower 
on  Acquisition  Programs  did  constitute  the  existing  policies  on  SPO  formation  and  manning.  Since  the 
AFSC  and  Air  Force  Logistics  Command  (AFLC)  merger,  these  policies  have  been  rescinded.  Also, 

AFMCR  500-1 1 ,  Integrated  Weapon  System  Management  (IWSM)  Model  for  Single  Managers. 

1 1 .  IMPLEMENTATION  TOOLS:  The  ASC/YX  SPO  Cadre  Developmenl  Team  is  currently  woikirx)  to 
finalize  a  process  flow  chart  and  guidebook  to  be  used  by  project  teams  who  are  establishing  either  a 
project  team,  SPO  cadre,  or  a  SPO.  The  SPO  Cadre  Development  Team  will  define  the  process  in  all 
functional  areas  and  determine  what  manpower  support  is  required  to  initialize  a  SPO.  The  process  will 
be  flowcharted  and  documented.  The  Team's  activities,  when  completed,  will  constitute  the  most  in- 
depth  analysis  and  guidance  available  on  the  formation  and  composition  of  a  project  team,  a  SPO 
Cadre,  and  a  SPO. 

12.  PLANNING  GUIDANCE:  The  SPO  Cadre  Development  Team  plans  to  address  each  of  these  areas 
in  development  of  our  guidance/products.  The  SPO  Cadre  Development  Team  will  provide  guidance  on 
the  estimated  number  of  person-hours,  by  functional  contribution  (e.g.,  systems  engineering,  acquisition 
logistics,  financial  management.  Program  Management,  contracts,  security,  etc.),  required  for  a  Pre- 
Milestone  0  project  team  to  transition  to  the  post-milestone  l/IV  formation  of  the  SPO.  This  guidance  will 
irKlude  a  breakout  of  contributions  by  functional  area,  along  with  any  special  security,  facilities, 
computers  (hardware  and/or  software),  or  other  resources  required  for  the  team  as  it  progresses  from  a 
proj^  team  to  a  formal  SPO.  The  Project  Team  aixl  SPO  Cadre  Guidebook  and  resource  matrix  will  be 
accessible  through  AFAMSUP. 

a.  DURATION:  While  the  single  manager  per  will  remain  intact  and  functioning  through  system 

cancellation,  retirement,  or  disposal,  the  actual  loc  -jn  of  the  program  office  will  most  likely  change  * 

from  one  location  to  another.  From  an  Air  Force  jriel  Command  (AFMC)  perspective,  a  weapon 

system  project/program  along  with  the  System  Program  Director  (SPD)  may  transition  from  a  product 
center  (ASC,  ESC,  SMC.  HSC)  to  one  of  the  logistic  centers  (WR-ALC,  SA-ALC,  (X-ALC,  CX)-ALC, 

SM-ALC)  during  its  life.  In  the  case  of  a  weapon  system  modification  program,  the  SPO  could  be  in  the 

single  manager's  office  at  one  of  the  ALCs.  The  philosophy  behind  the  IWSM  corKept  is  that  as  a 

program  evolves,  the  SPO  and  the  single  manager  need  to  be  located  where  it  makes  the  most  sense.  9 

b.  CONSTRAINTS:  The  program  manager  will  find  that  there  is  always  a  problem  with  obtaining 
personnel.  He  will  not  be  able  to  get  the  people  until  he  can  demonstrate  a  need  and  by  then  it  is 
sometimes  too  late.  Constraints  imposed  by  the  personnel  system,  regulations,  political  situation  (e.g., 
reduction  in  force,  cutbacks,  APDP  coding  on  positions,  changing  job  series  on  vacant  positions)  force 

every  manage'  to  continually  spend  much  of  his  time  fighting  to  maintain  his  present  manpower  strength,  I 

or  trying  to  fine  qualified  personnel  to  take  the  place  of  those  who  have  left.  See  the  Project  Team  and 
CPO  Cadre  Development  Guide  for  addition  information  on  these  subjects. 

c.  RESOURCES:  The  SPO  Cadre  Development  team  has  developed  a  matrix  which  identifies  the 
various  resource  requirements  for  ACAT I  aircraft  effort  project  teams.  SPO  cadres,  and  SPOs.  The 

matrix  can  be  found  the  Project  Team  and  SPO  Cadre  Development  Guide.  ^ 
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d.  LESSONS  LEARNED:  The  Project  Team  and  SPO  Cadre  Development  Guide  includes  various 
lessons  learned. 

e.  BEST  PRACTICES:  Probably  the  most  important  interlace  that  the  SPO  must  nurture  is  that  with 
the  user.  One  initiative  taken  on  by  a  program  team  was  to  brief  the  using  command  on  a  monthly  basis 
as  to  program  status,  issues  and  p^lems.  This  briefing  is  accomplished  by  the  program  manager  or 
one  of  his  deputies.  This  illustrates  to  the  user  that  they  are  a  valuable  partner  in  the  project  team  and 
worthy  of  high  level  attention  from  the  program  office.  Another  organization  at  ASC  has  initiated  a 
program  whereby  SPO  personnel  are  given  the  opportunity  to  visit  the  using  command  and  the  field 
activities.  They  are  allowed  to  inspect  arxf  work  on  the  weapon  systems  they  have  had  a  hand  in 
acquiring.  The  user  started  this  in  order  for  the  SPO  people  to  gain  a  greater  understanding  of  the  using 
environment  arxj  a  greater  appreciation  for  why  user  requirements  are  what  they  are.  See  the  Project 
Team  and  SPO  Cadre  Development  Guide  for  addition  information  on  this  subject. 

f.  TRAPS:  The  Project  Team  and  SPO  Cadre  Development  Guide  may  assist  when  encountering 
obstacles  in  attempts  to  manage  a  program  office. 
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1.  ELEMENT:  D77.  TBS  0.1. 9.5  {\FC93-3) 

2.  ELEMENT  TITLE:  Preliminary  Cost  Estimates 

3.  ELEMENT  0WNER(S):  Project  Team  (TPITs) 

4.  ELEMENT  STOCKHOLOER(S):  HQ  USAF.  Operating  Major  Commands  (MAJCOM)s,  ASC/FM, 
Project  Manager 

5.  REQUIREMENT:  Aeronautical  Systems  Division  Cost  Anaytysis  173-1, 17  Jan  89.  it  used  to  support 
budget  planning  process.  The  requirements  remain  the  same,  regardess  of  Acquisition  Category 
(ACAT)  level. 

6.  PURPOSE/OBJECnVES: 

a.  Purpose;  The  purpose  of  the  cost  estimate  is  to  support  the  PBS  process. 

b.  Objective;  The  objective  is  to  use  the  cost  estimate  to  get  a  wedge  in  the  Air  Force  PBS  at 
the  eartiest  opportunity. 

7.  DESCRIPTION:  The  need  to  perform  a  project  estimate  will  depend  on  the  planning  offices' 
abiNty  to  interject  the  estimated  project  costs  into  the  Air  Force  PBS.  The  PBS  submission  will 
only  address  the  years  included  in  the  Future  Years  Defense  Plan  (FYDP).  For  some  projects, 
this  may  only  represent  Concept  Exploration  (CE)  studies,  but  in  other  cases  it  could  include  a 
portions  of  both  Demonstration/Validation  (D/V)  or  Engineering  and  Manufacturing  Development 
(EMD)  activities.  If  it  is  not  expected  that  the  estimate  can  be  utilized  for  the  PBS.  this  estimating 
activity  may  be  deferred,  but  be  aware  that  the  Air  Staff  may  be  required  to  submit  a  fcjnding 
request  even  without  a  product  center  ii^t.  Regju^less,  the  cost  analyst  should  begin  collecting 
data  and  planning  the  estimating  activities. 

a.  If  the  estimate  is  to  be  included  into  the  Air  Force  PBS,  it  will  need  to  be  provided  to  the 
Operating  Command  for  review  and  approval  (Block  C9),  prior  to  the  submission  in  the  PBS  process. 
Historicalty,  the  PBS  call  to  Product  Center  organizations  is  in  the  spring  summer  of  odd-numbered 
years.  To  satisfy  this  schedule,  the  project  team  should  plan  to  have  the  initial  estimate  complete  and 
approved  by  the  Operating  Command  by  the  end  of  May.  The  estimate  can  then  be  incorporated  into 
the  field  P^  submission  to  the  Operating  Command,  or  the  Operating  Command  may  input  and  support 
the  estimate  during  their  PBS  review.  The  estimate  should  then  be  included  in  the  dilating  Command 
PBS  to  USAF.  If  approved,  the  estimate  would  be  included  in  the  Air  Force  PBS  to  Office  of  the 
Secretary  of  Defense  (OSD),  usually  in  April  of  the  even-numbered  years.  The  inclusion  of  the  estimate 
into  the  Air  Force  PBS  is  critical  in  that  it  is  the  first  step  in  identifying  and  programming  financial 
requirements  in  the  budget  process. 

b.  The  development  of  the  cost  estimate  can  be  grouped  into  five  major  activities; 

(1)  Task  definition  and  planning  -  this  effort  will  consist  of  defining  the  project  to  be 
estimated,  determining  the  scope  of  the  estimate,  assembling  the  estimating  team  and  assigning 
responsibilities,  and  defining  estimate  ground  rules,  assumptions,  and  constraints.  This  should  be 
documented  in  the  estimate  plan,  and  approved  by  project  management. 

(2)  Research  -  the  cost  analysts  will  perform  initial  data  analysis  to  determine 
appropriate  estimating  methodologies,  and  pertorm  data  collection  to  determine  if  information  can  be 
obtained  to  support  the  selected  estimating  approach(es). 

(3)  Develop  the  estimating  approach  -  the  preliminary  estimating  methods  are 
selected,  and  any  estimating  tools  would  be  updated  or  designed,  as  appropriate. 
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(4)  Perform  estimate  and  cross-checks  -  the  analysts  generate  the  detailed  estimates 
and  verify  the  results  with  any  appropriate  cross-checks  to  ensure  the  results  are  logical,  re^onable,  and 
complete. 


(5)  Documentation  and  approval  -  the  estimate  must  be  documented  and  provided  to 
project  manageinent  for  approval.  This  process  usually  involves  presentation  of  the  estimate  to  the 
senior  managers  assigned  to  the  project.  After  approval,  the  estimate  becomes  the  official  program 
estimate,  and  should  be  the  basis  for  all  program  estimate  “what  ifs*  and  budget  subrmssions  until 
updated  by  another  formal  program  estimate.  Maintainkx]  all  cost  documentation  is  vital. 

8.  ENTRANCeEXiT  CRITERIA: 

a.  Entrance:  The  need  for  a  projed  cost  estimate  at  this  phase  of  development  will  depend  on 
the  abHity  of  the  project  team  to  gel  the  estimated  project  costs  into  the  Air  Force  PBS. 

b.  Exit:  If  the  cost  estimate  is  for  submission  to  the  PBS  (BS  and  A4),  it  must  first  be  reviewed 
and  approved  by  the  project  manager  and  the  project  office  with  primary  responsibility  m  the  oper^ing 
MAXOM  (C9).  For  discussion  purposes,  it  is  assumed  that  this  will  be  the  Operating  Command 
requirements  organization. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  In  this  early  development  phase,  only  minimal  technical  and  programmatic 
information  is  available.  However,  to  derive  even  a  top  level  estimate  of  potential  costs,  the  project 
team  must  develop  a  minimal  program  framework,  to  be  priced  out.  Required  information  wilt  include 
system  descriptions,  developnieni  and  production  schedules,  quantities,  and  notional  acquisition 
strategy.  The  source  of  this  information  would  be  functional  (engineering,  manufacturing,  contracts, 
logistics,  test,  and  management  personnel)  and  Operating  Command  personnel.  Although  a  prefened 
concept  has  not  been  selected,  the  results  of  the  SCO  evaluations  (D9)  should  provide  information  on  a 
representative  program  alternative.  While  it  is  not  the  intent  of  tNs  block  to  estimate  the  cost  of  the 
preferred  concept,  the  results  of  the  SCO  evaluations  (Block  D9)  should  provide  information  on  potential 
program  alternatives.  This  could  result  in  a  range  of  estimates  to  provide  the  Operating  Command  in 
order  for  them  to  select  the  estimate  they  can  support  for  the  PBS. 

b.  Output:  The  results  of  the  analysis  should  be  formally  documented  and  approved  by  the 
project  director.  The  documentation  should  include  all  ground  rules,  assumptions,  and  programmatic 
information  that  is 

necessary  to  replicate  the  estimate  and  fully  support  cost  relationships  utilized.  If  the  estimate  will  be 
utilized  to  supp^  a  budget  submission,  the  documentation  should  be  accomplished  in  accordance  with 
ASDR  173-1  (Develop  Preliminary  System  CorK:ept  Options(SCOs)  D9),  (Write  Preliminary  Mission 
Need  Statement  (MNS)  Cl  2). 

10.  KEY  REFERENCES: 

a.  AFR  173-1 ,  The  Air  Force  Cost  Analysis  Program.  Specifies  the  objectives  and  functions, 
and  assigns  responsibilities  for  the  conduct  of  the  Air  Force  Cost  Analysis  program. 

b.  ASDR  173-1,  Aeronautical  Systems  Division  Cost  Analysis  Program.  17  Jan  89.  Provides 
policy,  procedures,  concepts,  and  responsibilKies  to  ASC  organizations  that  perform  cost  analysis, 
develop  cost  estimates,  and  corxluct  cost  studies. 

11.  IMPLEMENTATION  TOOLS: 

a.  The  AFSC  Cost  Estimating  Handbook,  Volume  I  &  II.  Provides  general  guidance  for 
estimating  and  estknate  documentation  information. 
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b.  The  AFSC  Fmancial  Mwiagement  Handbook  for  financial  information,  the  AFSC  Cost 
Estimating  Hartdbook,  volume  2.  provides  information  for  estimating  ASC  type  activities/programs. 

c.  The  ASC/FM  Cost  Workstation  for  an  automation  aid  and  application  software,  arxf 

d.  The  ASC  Cost  Data  Center  for  historicat  cost  data,  cost  models,  arxf  other  cost  related 
materials  and  references. 

12.  PLANNING  GUIOAN<£: 

a.  DURATION:  The  estimating  activities  at  this  point  are  typically  based  on  parametric  analysis 
and  should  take  2  to  4  months,  depending  upon  program  complexity,  data  availability,  arxf  number  of 
analysts  assigned. 

b.  CONSTRAINTS:  The  greatest  limitations  in  the  performance  of  the  estimate  are  lack  of 
program  definition  and  the  lack  of  reliable  historical  cost  information. 

c.  RESOURCES:  The  estimate  is  usually  performed  by  one  or  two  cost  analysts,  working  the 
estimate  as  a  primary  duty.  Engineering,  logistics,  and  program  management  personnel  would  each 
need  to  provide  40  -  80  hours  each  for  technical  support.  Computer  assets  are  considered  a  necessity 
for  both  computation  and  documentation. 

d.  LESSONS  LEARNED:  The  product  center  cost  staff  should  be  contacted  to  have  a  staff 
cost  analyst  assigned  as  a  focal  point  to  support  the  analysis  effort.  This  analyst  should  be  a  valuable 
resource  in  aiding  in  data  searches  and  estimating  metho^logy  selection  as  welt  as  supporting 
management  reviews.  Further,  the  cost  staff  may  be  able  to  provide  analysts  to  supp^  or  perform 
elements  of  the  estimate.  It  should  be  expected  that  many  program  variations  and  estimating  excursions 
will  be  performed  to  support  the  decision  making  process  >  each  of  these  should  be  documented  and 
tracked,  by  both  program  content  and  estimate  results.  If  contractors  are  performing  the  corx:ept  studies, 
they  are  usually  a  good  source  of  information. 

e.  BEST  PRACTICES: 

(1 )  The  cost  analyst  should  develop  a  comprehensive  estimate  plan  which  defines 
program  content,  describes  the  estimating  approach  and  the  estimate  schedule,  identifies  estimate  team 
ment)ers  arxj  assigns  responsibilities,  and  i^ntifies  any  estimate  groundrules  and  assumptions. 

(2)  The  project  office  should  be  able  to  improve  the  quality  and  accuracy  of  the  estimate 
if  it  can  anticipate  any  cost  estimating  issues  and  problems  at  the  earliest  opportunity.  If  fhis  can  be 
done,  the  project  officers  should  identify  these  estimating  needs  to  the  product  center  cost  staff.  If  the 
cost  staff  can  be  notified  early  enough,  directed  cost  research  or  data  collection  might  be  undertaken  to 
support  the  project  requirements.  Moreover,  the  staff  might  be  able  to  obtain  the  research  support  from 
either  Air  Force  or  OSD  cost  analysis  organizations. 

(3)  Be  sure  to  provide  a  detailed  description  of  the  programmatic  scope  of  what  is  being 
costed  •  What  is  in  and  what  is  out  of  the  estimate.  Scope  growth  is  biggest  driver  of  cost  growth  in  early 
development  programs.  Use  the  element  checklist  in  apperxfix  F  of  volume  I  of  the  AFSC  Cost 
Handbook  to  ensure  that  all  applicable  areas  are  costed. 

f.  TRAPS:  It  is  imperative  that  the  cost  analysts  identify  methodologies  and  data  requirements 
as  soon  as  possible  so  that  these  needs  can  be  made  known.  If  this  information  is  not  available,  work¬ 
around  must  be  made  to  maintain  the  estimating  scherkile  and  support  the  PBS  input  schedule.  It's 
imperative  to  establish  and  document  appropriate  groundmles  and  assumptions  tor  use  by  OSD  or  the 
Air  staff.  Also,  it  is  essential  that  the  estimating  arxf  functional  team  members  be  carefully  selected,  so 
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that  aN  necessary  information  can  be  derived  to  support  the  estimating  process.  Additionally,  it  is  critical 
that  others  doni  perceive  this  estimate  as  an  official  baselfoe  program  estimate,  since  akematives  have 
not  aM  been  selected. 
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1.  ELEMENT:  D  78. 1.1. 3.0  (IFC  93-3) 

2.  ELEMENT  TITLE;  Reveiw  New  Work 

3.  ELEIKNT  OWNER(S):  ASC/CC. 

4.  ELEMENT  STAKEHOLDER(S):  Primary;  Acquisition  Organization;  Secorxlary;  ASC/CC,  Customer, 
SuppHer(s),  and  any  other  affected  entity  that  may  have  a  material  interest  in  the  work  under 
corsideration. 

5.  REQUIREMENT:  AFSCR  550-14,  Act^isition  Strategy  Panel  (ASP)  Policy  Issues  Meeting  of 
19  Dec  91. 

6.  PURPOSE/  OBJECTIVES;  A  corporate  review  process  for  both  accepting  and  allocatir^  new  work 
for  ASC  Acquisition  Organizatiorts.  The  object  of  the  process  is  to  match  new  work  requirements  with 
available  resources. 

7.  DESCRIPTION;  (The  complete  New  Work  Process  Diagram  and  Block  Description  is  available  from 
ASC/CYNorASC/YXP.) 

a.  The  process  begins  when  new  work  enters  an  ASC  acquisition  organization  (Acq  Otg).  New 
work  can  come  from  a  wide  variety  of  sources.  In  conformance  with  the  intent  of  this  data  sheet,  the 
most  commonly  conceptualized  source  is  by  way  of  a  format  Program  Management  Document  (PMD). 
This  path  would  come  to  ASC  by  way  of  a  formal  Mission  Assignment  as  a  result  of  the  Mission 
Assignment  Process  at  HQ/AFMC  (D  21 ).  The  first  step  r^uires  the  Acq  Org  to  evaluate  the  new  work 
for  "appropriateness.*  This  check  ensures  the  new  work  is  compatible  with  the  mission  of  both  ASC  and 
Acq  O^.  From  this  evaluation,  the  Acq  Org  can  answer  the  questions,  "Should  the  New  Work  be  done?" 
and  "Should  the  New  Work  be  done  here?*.  If  either  answer  is  "NO,"  rejection  rationale  is  documented 
and  the  package  is  fonvarded  to  ASC  Command  section  for  disposition.  If  the  answers  are  "YES,"  the 
Acq  Org,  in  conjunction  with  functional  staffs  and  other  resource  owners,  evaluates  the  resource 
availability  to  meet  the  anticipated  requirements.  This  evaluation  answers  the  question  "Can  the  New 
Work  be  done?*.  If  the  answer  is  "NO,"  a  statement  of  shortfall  is  documented  and  the  package  is  again 
forwarded  to  the  Product  Center  (ASC)  Command  Section  for  disposition.  Notwithstanding  the  inherent 
right  to  redirect  the  New  Work,  the  Command  section  typically  concurs  and  organization  workload  and 
possibly  manpower  baselines  would  be  adjusted. 

b.  There  are  cases  where  the  answer  to  one  of  the  "screening"  questions  is  "NO."  Whether  the 
package  subsequently  arrives  at  the  Command  Section  with  rejection  rationale  or  a  statement  of 
shortfall,  alternative  dispositions  include  forwarding  to  another  Acq  Org  for  evaluation,  returning  to  the 
original  organization  with  additional  direction  or  requests  for  clarification  of  the  "NO,"  returning  to  the 
customer  explaining  the  reason  for  the  return,  or  submittirrg  to  the  Corporate  Level  Review  portion  of  the 
recommended  process  (as  administered  by  ASC/CYN,  the  process  caretaker). 

c.  The  Corporate  Level  Review  portion  of  the  process  begins  by  activating  the  Caretaker 
(ASC/CYN)  to  assemble  a  working  group  of  the  affected  organizations.  The  working  group  is  tasked  to 
work  the  unresolved  issues  and  recommend  a  solution  to  the  Command  Section.  The  Command  Section 
may  then  accept  the  working  group  resolution  or  have  the  ASC  Council  review  the  issues.  At  this  point, 
the  final  decision  is  reached  that  resolves  the  issue  and  allows  for  the  "Task  Go  Ahead*  or  returns  the 
new  work  to  the  customer  with  an  explanation  of  the  unresolvable  issue(s).  Returning  new  work  to  the 
customer  allows  the  customer  to  make  programmatic  changes  that  could  eliminate  the  obstacles  keeping 
ASC  from  accepting  and  initiating  the  new  work.  Notification  of  acceptance  of  new  work,  or  a  formal 
Mission  Assignment  would  than  support  the  next  step  in  this  flow  process.  Update  Phase  *0*  Plans  (D- 
22). 
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d.  This  process  was  approved  by  the  ASC  ASP  Board  in  Dec  92.  The  proc^  flow  chart  and 
acoxnpanying  block  descriptions  of  activities  within  and  relatiortships  between  activity  blocks  completes 
Phase  I  of  process  implementation.  Phase  II  remains  in  work  with  the  process  caret^er,  ASO/CYN. 

FuH  development  of  this  process  depends  on  the  completion  of  Phase  II.  Currently,  the  process  flow 
chart  and  block  descriptions  are  sufficient  for  use  within  an  acquisition  organization.  As  of  this  writing, 
this  process  has  not  been  exercised  as  a  standard  method  of  reviewing  and  allocating  new  work. 

8.  ENTRANCeEXIT  CRITERIA: 

a.  Entrance:  Any  work  that  enters  an  Acquisition  Organization  that  exceeds  their  Directed  • 

Mission,  Workload  Baseline,  or  Manpower  Baseline,  or  tasking  from  the  Command  Section  or  ASC 

Council. 

b.  Exit:  Notification  of  new  work  accepted  to  the  Command  Section,  new  work  package 
forwarded  to  the  Command  section  with  a  Statement  of  Shortfall.  Task  Go  Ahead  from  the  Commarrd 

Section  or  >^C  Council,  or  notification  from  the  Caretaker  that  the  new  work  package  has  been  referred  § 

back  to  the  customer  for  changes  in  requirements. 

9.  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  A  letter  of  assignment  from  the  Air  Force  Materiel  Command  Mission  Assignment 

Process  (Block  D-21 ,  Assign  Lead  arxf  Support  Centers(AFMC])  by  way  of  ASC/CC,  or  any  work  that  _ 

exceeds  the  organizations  Directed  Mission,  Workload  Baseline,  Manpower  Baseline.  In  general,  outside 
the  formal  chaiinel  from  a  Mission  Assignment  from  AFMC  through  ASC/CC,  work  may  come  from  many 
source,  (i.e.  internal  (ECP,  rework,  etc.),  or  external  (changing  customer  needs,  emerging  technologies, 
change  of  threat,  etc.)). 

b.  Outputs:  The  Acquisition  Organizations  acceptance  of  the  New  Work,  ASC  Command 
section  acceptance  of  notification  of  New  Work  from  the  Acquisition  Organization,  Task  Go  Ahead  from 
the  Command  section  or  ASC  Council,  or  establishment  of  a  System  Program  Office  (SPO).  Within  the 
process,  the  capability  exists  for  the  ASC/CC  to  return  new  work  to  its  origin  for  rework  of  requirements 
and  with  conditions  for  reconsideration  by  ASC. 

10.  KEY  REFERENCES:  ASCR  800-3,  New  Work  CPT  Process  Diagram,  New  Work  CPT  Process 
Guide. 

11.  IMPLEMENTATION  TOOLS:  As  of  this  writing  (May  93),  ASC/CYN  as  Caretaker  of  this  process, 
has  the  Acquisition  Strategy  Panel  (ASP)  action  item  to  write  and  bring  into  official  use  the 
implementation  guide  to  support  the  New  Work  Review  Process. 

12.  PLANNING  GUIDANCE: 

a.  DURATION:  None  established  until  adaptation  of  implementation  guide  currently  in  work  by 
ASC/CYN,  the  New  Work  Review  Process  Caretaker. 

b.  CONSTRAINTS:  Further  development  of  a  working  definition  for  Directed  Mission,  Workload 

Baseline  and  Manpower  Baseline.  I 

c.  RESOURCES:  ASC/CYN  has  to  staff,  write,  and  test  the  implementation  guide.  A  detailed 
explanation  of  the  process  flow  and  process  action  block  descriptions  are  available  through  ASC/CYN  or 
ASC/YXP. 

d.  LESSONS  LEARNED:  None  Identified.  This  process  has  not  been  matured  to  the  point  I 

where  it  can  be  applied  to  a  new  work  proposal. 
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e.  BEST  PRACTICES:  This  data  sheet  description  of  the  New  Work  Review  Process  is  a  best 
practice. 

f.  TRAPS;  None  Identified.  The  process  has  ncrt  been  fully  applied  to  a  trial  situation  for 
debugging.  The  debugging  process  is  inteixfed  for  Phase  II  impleme^tion. 
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1.  ELEMENT:  D  79.  TBS  1. 3.5.0  (IFC  93-3) 

2.  ELEMENT  TITLE:  Review  New  Work 

3.  ELEMENT  OWNER(S):  ASC/CC. 

4.  ELEMENT  STAKEHOLOER(S):  Primary:  Acquisition  Organization;  Secondary:  ASC/CC.  Customer, 
Supplier(s).  and  any  other  affected  entity  that  may  have  a  material  interest  in  the  work  under 
consideration. 

5.  REQUIREMENT:  AFSCR  550-14,  Acquisition  Strategy  Panel  (ASP)  Policy  Issues  Meeting  of 
19  Dec  91. 

6  PURPOSE/ OBJECTIVES:  A  corporate  review  process  for  both  accepting  and  allocating  new  work 
for  ASC  Acquisition  Organizations.  The  object  of  the  process  is  to  match  new  work  requirements  with 
available  resources. 

7  DESCRIPTION:  (The  complete  New  Work  Process  Diagram  and  Block  Description  is  available 
from  ASC/CYN  or  ASC/YXP.) 

a.  The  process  begins  when  new  work  enters  an  ASC  acquisition  organization  (Acq  Org).  New 
work  can  come  from  a  wide  variety  of  sources.  In  conformance  with  the  intent  of  this  data  sheet,  the 
most  commonly  corx:eptualized  source  is  by  way  of  a  formal  Program  Management  Document  (PMD). 
This  path  would  come  to  ASC  by  way  of  a  formal  Mission  Assignment  as  a  result  of  the  Mission 
Assignment  Process  at  HQ/AFMC  (D  21 ).  The  first  step  r^uires  the  Acq  0^  to  evaluate  the  new  work 
for  'appropriateness.*  This  check  ensures  the  new  work  is  compatible  wlh  the  mission  of  both  ASC  and 
Acq  O^.  From  this  evaluation,  the  Acq  Org  can  answer  the  questions,  "Should  the  New  Work  be  done?" 
and  "Should  the  New  Work  be  done  here?".  If  either  answer  is  "NO."  rejection  rationale  is  documented 
and  the  package  is  forwarded  to  ASC  Commaixl  section  for  disposition.  If  the  answers  are  "YES,"  the 
Acq  Org,  in  conjunction  wlh  functional  staffs  and  other  resource  owners,  evaluates  the  resource 
availabiWy  to  meet  the  anticipated  requirements.  This  evaluation  answers  the  question  "Can  the  New 
Work  be  done?*.  If  the  answer  is  "NO,"  a  statemen  of  shortfall  is  documented  and  the  package  is  again 
fonwarded  to  the  Product  Cerier  (ASC)  Command  Section  for  disposlion.  Notwihstanding  the  inherent 
right  to  redirect  the  New  Work,  the  Command  Section  typically  concurs  and  organization  workload  and 
possibly  manpower  baselines  would  be  adjusted. 

b.  There  are  cases  where  the  answer  to  one  of  the  "screening"  questions  is  "NO".  Whether  the 
package  subsequently  arrives  at  the  Command  Section  wlh  rejection  rationale  or  a  statement  of 
shortfall,  alemative  disposlions  include  forwarding  to  annher  /\cq  Org  for  evaluation,  returning  to  the 
original  organization  wlh  addlional  direction  or  requests  for  clarification  of  the  "NO."  returning  to  the 
customer  explaining  the  reason  for  the  return,  or  submiting  to  the  Corporate  Level  Review  portion  of  the 
recommended  process  (as  administered  by  ASC/CYN,  the  process  caretaker). 

c.  The  Corporate  Level  Review  portion  of  the  process  begins  by  activating  the  Caretaker 
(ASC/CYN)  to  assemble  a  working  group  of  the  affected  organizations.  The  working  group  is  tasked  to 
work  the  unresolved  issues  and  recommend  a  solution  to  the  Command  Section.  The  Command  Section 
may  then  accept  the  working  group  resolution  or  have  the  ASC  Council  review  the  issues.  At  this  point, 
the  final  decision  is  reached  that  resolves  the  issue  and  allows  tor  the  Task  Go  Ahead*  or  returns  the 
new  work  to  the  customer  wlh  an  explanation  of  the  unresolvable  issue(s).  Returning  new  work  to  the 
customer  allows  the  customer  to  make  progremmatic  chartges  that  could  eliminate  the  obstacles  keeping 
ASC  from  accepting  and  inliating  the  new  work.  Notification  of  acceptance  of  new  work,  or  a  formal 
Mission  Assignment  would  than  support  the  next  step  in  this  ftow  process.  Establish  a  System  Program 
Office  (D-76). 
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d.  This  process  was  approved  by  the  ASC  ASP  Board  in  Dec  92.  The  process  flow  chart  and 
accompanying  block  descriptions  of  activities  within  and  relaliortships  between  activity  blocks  completes 
Phase  I  of  process  implementation.  Phase  II  remains  in  work  with  the  process  caretaker,  ASD/CYN. 

Full  development  of  this  process  depends  on  the  completion  of  Phase  II.  Currently,  the  proc^  flow 
chart  arxf  block  descriptions  are  sufficient  for  use  within  an  acquisition  organization.  As  of  this  writirx), 
this  process  has  not  been  exercised  as  a  standard  method  of  reviewing  and  allocating  new  work. 

8  ENTRANCE/EXIT  CRITERIA: 

a.  Entrance;  Any  work  that  enters  an  AcquisKion  Organization  that  exceeds  their  Directed 
Mission,  Workload  Baseline,  or  Manpower  Baseline,  or  tasking  from  the  Command  section  or  ASC 
Council. 

b.  Exit:  Notification  of  new  work  accepted  to  the  Command  section,  new  work  package 
forwarded  to  the  Command  section  with  a  Statement  of  Shortfall,  Task  Go  Ahead  from  the  Command 
Section  or  ASC  Council,  or  notification  from  the  Caretaker  that  the  new  work  package  has  been  referred 
back  to  the  customer  for  changes  in  requirements. 

9  KEY  INPUTS  AND  OUTPUTS: 

a.  Inputs:  A  letter  of  assignment  from  the  Air  Force  Materiel  Command  Missbn  Assignment 
Process  (Block  D-75,  Assign  Lead  arxl  Support  Centers  (AFMC))  by  way  of  ASC/CC,  or  any  work  that 
exceeds  the  organizations  Directed  Mission,  Workload  Baseline,  Manpower  Baseline.  In  general,  outside 
the  formal  channel  from  a  Mission  Assignment  from  AFMC  through  ASC/CC,  work  may  come  from  many 
source,  (i.e.  internal  (ECP,  rework,  etc.),  or  external  (changing  customer  needs,  emerging  technologies, 
change  of  threat,  etc.)). 

b.  Outputs;  The  Acquisition  Organizations  acceptance  of  the  New  Work,  ASC  Command 
Section  acceptance  of  notification  of  New  Work  from  the  Ao^isition  Organization,  Task  Go  Ahead  from 
the  Command  Section  or  ASC  Council,  or  establishment  of  a  System  Program  Office  (SPO).  Within  the 
process,  the  capability  exists  for  the  ASC/CC  to  return  new  work  to  its  origin  for  rework  of  requirements 
and  with  conditions  for  reconsideration  by  ASC. 

10.  KEY  REFERENCES:  ASCR  800-3,  New  Work  CPT  Process  Diagram,  New  Work  CPT  Process 
Guide. 

11.  IMPLEMENTATION  TOOLS;  As  of  this  writing  (May  93),  ASC/CYN  as  Caretaker  of  this  process, 
has  the  Acquisition  Strategy  Panel  (ASP)  action  item  to  write  and  bring  into  official  use  the 
implementation  guide  to  support  the  New  Work  Review  Process. 

12.  PLANNING  GUIDANCE: 


a.  DURATION:  None  established  until  adaptation  of  implementation  guide  currently  in  work  by 
ASC/CYN,  the  New  Work  Review  Process  Caretaker. 

b.  CONSTRAINTS:  Further  development  of  a  working  definition  for  Directed  Mission,  Workload 
Baseline  and  Manpower  Baseline. 

c.  RESOURCES:  ASC/CYN  has  to  staff,  write,  and  test  the  implementation  guide.  A  detailed 
explanation  of  the  process  flow  and  process  action  block  descriptions  are  available  through  ASC/CYN  or 
ASC/YXP. 
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d.  LESSOfG  LEARNED;  None  Identified.  This  process  has  not  been  matured  to  the  point 
where  it  can  be  applied  to  a  new  work  proposal. 

e.  BEST  PRACTICES:  This  data  sheet  description  of  the  New  Work  Review  Process  is  a  best 
practice. 

t.  TRAPS:  None  Identified.  The  process  has  not  been  fuUy  applied  to  a  trial  situation  for 
debugging.  The  debugging  process  is  intended  for  Phase  II  Implementation. 
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APPENDIX  E 
LIST  OF  ACRONYMS 


ACAT 

ACC 

ADM 

ADP 

AETC 

AFAC 

AFAE 

AFAM 

AFCAA 

AFFARS 

AFI 

AFISA 

AFIT 

AFLC 

AFMC 

AFOTEC 

AFPG 

AFR 

AFSAA 

AFSARC 

AFSC 

AFSCR 

ALC 

ALLCARS 

AMS 

AP 

APB 

APDP 

ARPA 

ASC 

ASP 

ASPM 

ASR 

ASUSD(P&A) 

ATD 

ATPS 

ATTD 


Acquisition  Category  (level) 

Air  Combat  Command 

Acquisition  Decision  Memorandum;  Advanced  Development  Model 

Automated  Data  Processing 

Air  Education  and  Training  Command 

Air  Force  Acquisition  Circular 

Air  Force  Acquisition  Executive 

Air  Force  Acquisition  Model 

Air  Force  Cost  Analysis  ^ncy 

Air  Force  Federal  Arxiuisition  Re^jlation  Supplement 

Air  Force  Instruction 

Air  Force  Intelligence  Support  Agency 

Air  Force  Institute  of  Technology 

Air  Force  Logistics  Command 

Air  Force  Materiel  Command 

Air  Force  Operational  Test  and  Evaluation  Center 

Air  Force  Planning  Guidance 

Air  Force  Regjiation 

Air  Force  Studies  and  Analysis  Agency 

Air  Force  Systems  Acquisition  Review  Council 

Air  Force  Systems  Command;  Armed  Forces  Staff  College 

Air  Force  Systems  Command  Regulation 

Air  Logistics  Center 

Automated  Lessons  Learned  Capture  &  Retrieval  System 

Acquisition  Management  System 

Acquisition  Plan 

Acquisition  Program  Baseline 

Acquisition  Professional  Development  Program 

Advanced  Research  Projects  Agency 

Aeronautical  Systems  Center 

Acquisition  Strategy  Panel 

Armed  Services  Pricing  Manual 

Acquisition  Strategy  Report 

Assistant  Under  Sectary  of  Defense  for  Programs  &  Acquisition 

Advanced  Technology  Demonstration 

Automated  Test  Planning  System 

Advanced  Technology  Transition  Demonstration  (program) 


» 


BAA 

BAFO 

BCD 

BES 

BOCO 

BPAC 

BPPBS 


Broad  Agency  Announcement 
Best  and  Final  Offer 

Baseline  Concept  Description;  Baseline  Concept  Document 

Budget  Estimate  Submission 

Buying  Office  Contracting  Official 

Budget  Program  Activity  Code 

Biennial  Programming,  Planning,  and  Budgeting  System 


» 
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CAE 

CAG 

CAIQ 

CALS 

CAP 

CARD 

CARS 

CBO 

CBT 

CCA 

CCB 

CDRL 

CE 

CE&D 

CER 

CG 

C3ISC 

CIA 

CICA 

CIM 

CINC 

CIP 

CITIS 

CJCS 

CMN 

CO 

COD 

COE 

COEA 

CONOPS 

COTS 

CPA 

CPAF 

CPFF 

CPIF 

CPT 

CR 

CRLCMP 

CRWG 

CSAF 

CSC 

CSWG 

CTS 


Component  Acquisition  Executive 
Concept  Action  Group;  Cost  Analysis  Group 
Cost  Analysis  Improvement  Group  (DOD)(OSD) 

CompiAer-Aided  Acquisition  &  Logistics  ^pport 

Capability  Assessment  Package:  Concept  Assessment  Package;  Contract  Acquired 
Property 

Cost  Analysis  Requirements  Document 
Consolidated  Acquisition  Reporting  System 
Commerce  Business  Daily 
Computer  Based  Training 

Component  Cost  Analysis  (formally  refened  to  as  ICE) 

Change  Control  Board:  Configuration  Control  Board 

Contract  Data  Requirements  List 

Concept  Exploration;  Critical  Experiment;  Cunent  Estimate 

Concept  Exploration  &  Definition 

Cost  Estimating  Relationship 

Chairman's  Guidance  (document) 

Command,  Control.  Communications,  &  Intelligence  Systems  Committee 
Central  Intelligence  Agency 
Competition  in  Contracting  Act  (1984) 

Corporate  Information  Management 
Commander  in  Chief 

Component  Improvement  Program  (DIA);  Critical  Intelligence  Parameter 

Contractor  Integrated  Technical  Information  Service 

Chairman  of  the  Joint  Chiefs  of  Staff 

Corporate  Management  Network;  Critical  Mission  Need 

Contracting  Officer  (Air  Force) 

Cooperative  Development  an^or  (Cooperative  Opportunities  Docuntent 
Center  of  Excellence 

Cost  and  Operational  Effectiveness  Analysis 

(Concept  of  Operations 

(Commercial  Off  the  Shelf 

Chairman's  Program  Assessment 

Cost-Plus-Award  Fee 

Cost-Plus-Fixed  Fee 

Cost-Plus-Incemive  Fee 

Critical  Process  Team 

Clarification  Request;  Cost  Reimbursement 

Computer  Resources  Life  Cycle  Management  Plan 

Comjxjter  Resources  Working  Group 

Chief  of  Staff  of  the  Air  Force 

(Computer  Software  Component;  Conventional  Systems  (Committee 
(Commercial  Supportability  Working  Group 
Critical  Intelligence  Parameters  Threat  Status 


DA  -  Department  of  the  Army 

DAB  Defense  Acquisition  Board 

DAC  Designated  Acquisition  (Commander 

DAE  Defense  Acquisition  Executive 

DAM  Defense  Acquisition  Management 

DCS  -  Deputy  Chief  of  Staff 

DEA  Data  ^change  Agreement 

DFARS  Defense  Federal  Acquisition  Regulation  Supplement 

DFAS  Defense  Finance  and  Accounting  Service 
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Dl 

DIA 

DiS 

DMRD 

DOD 

DODD 

DOE 

DOT&E 

DPG 

DPMI 

DPRB 

DR 

DRFP 

DSMC 

DTC 

DT&E 

DTE 

DTIC 

DUSD(IP) 


EMD 


FAR 

FEBA 

FLOT 

FMS 

FOA 

FOC 

FSC 

FTD 

FY 

FYDP 


GFE 

GFP 

GOCO 

GUM 


HIFI 

HOI 

HSI 


lASP 

ICA 

ICD 

ICE 

ICO 

IFC 

ILSM 


Director  of  Intelligence 
Defense  Intelligence  Agency 
Defense  Investigative  Service 
Defense  Management  Report  Decision 
Department  of  Defense 
Department  of  Defense  Directive 
Department  of  Energy 

Developmental  Operational  Test  and  Evaluation 

Defense  Planning  Guidance 

Deputy  Project  Manager  for  Logistics 

Defense  Planning  and  Resource  Board 

Deficiency  Report 

Draft  Request  for  Proposal 

Defense  Systems  Management  College 

Design-to-C<»t 

Development  Test  &  Evaluation 

Developmental  Test  and  Evaluation 

Defense  Technical  Information  Center 

Deputy  Under  Secretary  of  Defense  (International  Programs) 


Essential  Elements  of  Friendly  Information 
Engineering  &  Manufacturing  Development 


Federal  Acquisition  Regulation 

Forward  Edge  of  the  Battle  Area  (obsolete  •  see  FLOT) 

Forward  Line  of  Troops 

Foreign  Military  Sales 

Field  Operating  Agency 

Full  Operational  Capability 

Federal  Supply  Classification 

Foreign  Technology  Division 

Fiscal  Year 

Future  Year  Defense  Program 


Government  Furnished  Equipment 
Government  Furnished  Property 
Government-Owned,  Contractor-Operated  (facility) 
Guidance  Update  Memorandum 


Helpful  Information  for  Industry 
Headquarters  Operating  Instmction  (AF) 
Human  Systems  Integration 


Integrated  Acquisition  Strategy  Process 
Independent  Cost  Analysis 
Interface  Control  Document/Drawing 
Independent  (^t  Estimate 
IntelligerKe  Counterpart  Officer 
Integrated  Flow  Chart 
Integrated  Logistics  Support  Manager 


ILSP 

IMP 

IMPACTS 

IMS 

IOC 

IPA 

IPP 

IPR 

IPS 

IPT 

IR&D 

ISO 

ISWG 

IWSM 

IWSMP 

IWSP 


J&A 

JAG 

JPATS 

JPD 

JRD 

JROC 

JSCP 

JSR 


KO 

KR 

KT 


LCC 

LLD 

LMIS 

LSA 

LSAR 


MAA 

MADP 

MAP 

MAJCOM 

MAPAT 

MCR 

MDA 

MDAP 

MFP 

MGM 

MIG 

MIL 

MIL-SPEC 

MIL-STD 


Integrated  Logistics  Support  Plan 
Integrated  Master  Plan 

Integrated  Manpower,  Personnel  and  Comprehensive  Training  &  Safety 
Integrated  Master  Schedule 
Initial  Operating  Capability 
Integrated  Program  Assessment 

IMPACTS  Program  Plan;  Industrial  Preparedness  Planning;  Industrial 
Preparedness  Program 

Intelligeince  Production  Requirement;  In  Progress/Process  Review 

Integrated  Program  Summary 

Independent  Product  Team;  Integrated  Product  Team 

Independent  Research  &  Development 

Information  Systems  Directive 

Intelligence  Support  Working  Group 

Integrated  Weapon  System  Management 

Integrated  Weapon  System  Master  Plan 

Integrated  Weapon  System  Planning 


Justification  and  Approval 
Ju^e  Advocate  General 
Joint  Primary  Aircraft  Training  System 
Joint  Potential  Designator 
Justification  Review  Document 
Joint  Requirements  Oversight  Courxiil 
Joint  Strategic  Capabilities  Plan 
Joirrt  Strategy  Review 


Contracting  Officer  (Navy) 

Contractor 

Contract 


Life  Cycle  Cost 
Lessons  Learned  Database 
Logistics  Management  Information  System 
Logistics  Support  Analysis 
-  Logistics  Supix)rt  Analysis  Record 


Mission  Area  Analysis;  Mission  Area  Assessment 
Mission  Area  Development  Plan 
Mission  Assignment  Factor 
Major  Command  (AF) 

Mission  Assignment  Process  Action  Team 

Manufacturing  Capabilities  Requirement  (assessment) 

Milestone  Decision  Authority 

Major  Defense  Acquisition  Program 

Major  Fielding  Plan;  Major  Force  Program 

Materiel  Group  Manager 

Major  Issues  Guidance 

Military 

Military  Specification 
Military  Standard 
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MIPR 

MNA 

MNS 

MOA 

MOE 

MOO 

MOP 

MPC 

MPLCC 

MR 

MRFP 

MRSA 

MRTFB 

MS 


Military  Interdepartmental  Purchase  Rec^jest 

Mission  Need  Arralysis 

Mission  Need  Statement 

Memorandum  of  A^eement 

Measure  of  EHectiveness 

Measures  of  Outcome 

Measure  of  Performance;  Memorandum  of  Policy 

Most  Probable  Cost 

Most  Probable  Life  Cycle  Cost 

Modification  Request 

Multirole  Forces  Project 

Material  Readiness  Support  Activity 

Major  Range  and  Test  Facility  Base 

Mil^one 


NAECON 

NAIC 

NASP 

NCP 

NDI 

NMSD 

NOCA 

NSA 

NWR 


National  Aerospace  Electronics  Convention 
National  Air  Intelligerx^  Center 
National  Aerospace  Plane 
Nuclear  Certification  Plan 
Nondevelopmental  Item 
National  Military  Strategy  Document 
Notice  of  Contract  Award 
National  Security  Agency 
New  Work  Review 


O&S 

OAS 

ODC 

CDS 

OPR 

ORD 

OSD 

OT&E 

OTP 


Op^ation  and  Support 

Office  of  Aerospace  Studies;  Office  of  the  Assistant  Secretary 

Ozone  Depleting  Chemical 

Ozone  Depleting  Substance 

Office  of  Primary  Responsibility 

Operational  Requirements  Document 

Office  of  the  Secretary  of  Defense 

Operational  Test  and  Evaluation 

Operational  Test  Plan 


•  • 


PAA 

PA&E 

PB 

PBD 

PC 

PCM 

PCO 

PD 

PDM 

PDP 

PE 

PEM 

PEO 

PERT 

PGM 

P-HSI 

P-IPP 


Program  Alternatives  Analysis 
Program,  Analysis  and  Evaluation 
President's  Bu^t;  Program  Baseline 
Program  Budget  Decision 

Personal  Cornputer;  Product  Center;  Program  Coordinator 

Price  Competition  Memorandum;  Program  Cost  Management 

Procuring  Contracting  Officer 

Program/Project  Director 

Program  Decision  Memorandum 

Program  Decision  Package;  Program  Development  Plan 

Planning  Estimate;  Program  Element 

Program  Element  Monitor  (AF) 

Program  Executive  Officer 

Program  Evaluation  and  Review  Technique 

Program  Group  Manager 

Preliminary  Human  Systems  Integration  Plan 

Preliminary  IMPACTS  Program  Plan 
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PLCCE 

- 

Program  Life  Cycle  Cost  Estimate 

PM 

- 

Program/Project  Manager 

PMD 

- 

Program  Managemertt  Decision;  Program  Management  Directive 

PMMA 

- 

Product  Management  Manpower  Allocation 

PMMEB 

- 

Program  Management  Mission  Element  Board 

PMP 

- 

Procurement  Management  Plan 

PMS 

- 

Procurement  Management  System;  Program  Management  System 

PMSS 

- 

Program  Manager's  Support  System 

PNM 

- 

Price  Negotiation  Memorandum 

POC 

- 

Point  of  Contact 

POE 

- 

Program  Office  Estimate 

POM 

- 

Program  Objective  Memorandum 

PPAP 

- 

Pollution  Prevention  Action  Plan 

PPBS 

- 

Planning,  Programming,  and  Budget  System 

PPI 

- 

POM  Preparation  Instnjction 

PPP 

- 

Program  Protection  Plan 

PR 

- 

Purchase  Request 

PRAG 

- 

Performance  Risk  Analysis  Group 

PRDA 

- 

Program  Research  and  Development  Announcement 

PSCO 

- 

Preliminary  Systems  Concept  Option 

PSM 

- 

Procurement  Strategy  Model;  Professional  Staff  Member  (Congress) 

PTO 

* 

Principal  Test  Organization 

QA 

Quality  Assurance 

QC 

- 

Quality  Control 

QNA 

• 

Quantitative  Needs  Assessment 

RAPID 

. 

Requirements  Analysis  Program  Interface  Design 

RAS 

- 

Requirements  Allocation  Sheet 

RAT 

- 

Resource  Allocation  Team 

RCAT 

- 

Resource  Allocation  Category 

RCC 

- 

Request  for  Contract  Clearance 

ROM 

- 

Requirements  C<}iTelation  Matrix  (AF) 

RDT&E 

- 

Research,  Development,  Test  and  Evaluation 

RFI 

- 

Ready  for  Issue;  Request  for  Information 

RFP 

- 

Recfuest  for  Proposal 

RFQ 

- 

Request  for  Question 

RMP 

- 

Risk  Management  Plan 

ROM 

- 

Read  Only  Memory;  Rough  Order  of  Magnitude 

RTO 

* 

Responsible  Test  Organization 

S&T 

. 

Science  and  Technology 

SAE 

- 

Sen/ice  Acquisition  Executive 

SAF 

- 

Secretary  of  the  Air  Force 

SAF/AQ 

- 

Assistant  Secretary  of  the  Air  Force  tor  Acctoisition 

SAG 

- 

Studies  Advisory  Group  (Army) 

SAP 

- 

Special  Access  Program 

SBD 

- 

Systematic  Task  Diagram 

SBIR 

- 

Small  Business  Innovation  Research 

SCO 

- 

System  Concept  Option 

SCP 

- 

Senrice  Cost  Position;  System  Concept  Paper 

SECAF 

- 

Secretary  of  the  Air  Force 

*) 
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SECDEF 

- 

Secretary  of  Defense 

sea:m 

- 

Systems  Engineering/Configuration  Management 

SEMP 

- 

Systems  Engineering  Management  Plan 

SEMS 

- 

Systems  Engineering  Master  Schedule 

SEP 

- 

Systems  Engineering  Process 

SIC 

- 

Standard  Industrial  Classification 

SLIC 

- 

Systems  &  Logistics  Integration  Capability 

SMM 

- 

System  Maturity  Matrix 

SMP 

- 

Security  Master  Plan 

SOR 

- 

Source  of  Repair;  Specific  Operatiortal  Requirement 

SOW 

- 

Statement  of  Work 

SPD 

- 

System  Program/Project  Director 

SPO 

- 

System  Program/Project  Office  (AF) 

SRB 

- 

Solicitation  Review  Board 

SRD 

- 

System  Requirements  Document 

SS 

- 

S^rce  Selection 

SSA 

- 

Software  Support  Agency:  Source  Selection  Authority 

SSAC 

- 

Source  Selection  Advisory  Council 

SSC 

- 

Strategic  Systems  Committee 

SSEB 

- 

Source  Sel^ion  Evaluation  Board 

SSET 

- 

Source  Selection  Evaluation  Team 

SSMG 

- 

Source  Selection  Management  Group 

SSMP 

- 

System  Security  Master  Plan 

SSP 

- 

S^rce  Selection  Plan 

STA 

- 

System  Threat  Assessment 

STAR 

- 

System  Threat  Assessment  Report 

STD 

- 

Software  Test  Description;  Standard 

STIP 

- 

Strategic  Technology  Investment  Plan 

SYSREP 

• 

Systems  Representative 

TAP 

. 

Technical  Area  Plan 

TAR 

- 

Threat  Assessment  Report 

TBS 

- 

Task  Breakdown  Structure 

TD 

- 

Test  Director 

T&E 

- 

Test  &  Evaluation 

TED 

- 

Threat  Environment  Description;  Threat  Environment  Document 

TEMP 

- 

Test  and  Evaluation  Master  Plan 

TEP 

- 

Threat  Environment  Projection 

TIRR 

- 

Technology  Investment  Recommendation  Report 

TISC 

- 

Threat  Intelligence  Support  Council 

TLS 

- 

Time  Line  Sheet 

TM 

- 

Test  Manager 

TMC 

- 

Technical  Management  Course;  Test  Management  Council 

TMP 

- 

Technology  Master  Plan 

TPD 

- 

Threat  Planning  Document 

TPIPT 

- 

Technical  Planning  Integrated  Product  Team 

TPM 

- 

Technical  Performance  Measurement 

TPWG 

- 

Test  Plan  Working  Group 

TO 

- 

Total  Quality 

TSG 

- 

Threat  Steering  Group 

TTO 

- 

Technology  Transition  Office 

TWG 

" 

Threat  Working  Group 

USAF 

. 

United  States  Air  Force 

» 
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USD<A) 

USO/AO 


VCXS 

VCSA 

VCSAF 


WBS 

WL 

WSMP 


Under  Secretary  of  Defense  for  AcquisAion 
Under  Secretary  of  Defense  Action  Officer 


Vice  Chairman  of  the  Joint  Chiefs  of  Staff 
Vice  Chief  of  Staff  (Army) 

Vice  Chief  of  Staff  (Air  Force) 


Wotft  Breakdown  Structure  * 

Wright  Laboratory 

Weapon  System  Master  Plan 
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mission  need  analysis  description,  3-5 
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development  summary,  3-7 
development  task  description,  3-9 
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perform  mission  area  assessment  perform,  3-3 
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milestone  review,  4-24 
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APPENDIX  G 


Process  Guide  Comment/Suggestion  Form 

We  would  like  your  help  to  make  this  guide  a  more  complete,  accurate  and  useful 
product  for  everyone  to  use.  Please  provide  any  relevant  comments,  suggestions, 
acquisition  lessons  learned,  best  practices  or  traps  from  your  experience  which  you 
believe  could  improve  this  product  and  help  others.  If  you  see  something  which  is  out 
of  date  or  incorrect,  please  tell  us  so  we  can  change  it.  Use  additional  sheets  if 
necessary.  When  complete,  fold  so  the  address  on  the  rear  is  visible,  staple,  add 
postage  (if  necessary)  and  drop  in  the  mail. 

SUGGESTIONS/COMMENTS; 


I 


> 


I 


» 


LESSONS  LEARNED/BEST  PRACTICES/TRAPS 


> 


I 

NAME: _  Office/Phone: _ 

Is  it  okay  of  we  call  you  regarding  these  inputs?  (circle  one)  YES  NO 


Na¥t9 


» 


THANK  YOU! 


) 


» 


» 


I 


ASC  YXD  BMg  2041 

ATTN:  Program  Daveiopment  Process  Team 

2511  L  Street  i 

WPAFB  OH  45433*7503 
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